[EGIT] [core/efl] master 01/01: edje - file set - use vpath for edje files now too like evas images
raster pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=90e8ad8d7dec453fa0037792cb6e2e04bdeadc8b
commit 90e8ad8d7dec453fa0037792cb6e2e04bdeadc8b
Author: Carsten Haitzler (Rasterman)
Date: Mon May 9 19:37:48 2016 +0900
edje - file set - use vpath for edje files now too like evas images
---
src/lib/edje/edje_edit.c| 13 -
src/lib/edje/edje_load.c| 12 +++-
src/lib/edje/edje_private.h | 2 ++
src/lib/edje/edje_smart.c | 42 --
4 files changed, 61 insertions(+), 8 deletions(-)
diff --git a/src/lib/edje/edje_edit.c b/src/lib/edje/edje_edit.c
index da63dd7..bd5552a 100644
--- a/src/lib/edje/edje_edit.c
+++ b/src/lib/edje/edje_edit.c
@@ -189,14 +189,25 @@ _edje_edit_efl_file_file_set(Eo *obj, Edje_Edit *eed,
const char *file, const ch
*(GROUP parts or BOX/TABLE items pointing to non-existent/renamed
*groups).
*/
+ Efl_Vpath_File *file_obj =
+ efl_vpath_manager_fetch(EFL_VPATH_MANAGER_CLASS, file);
+ efl_vpath_file_do(file_obj);
+ // XXX:FIXME: allow this to be async
+ efl_vpath_file_wait(file_obj);
+ file = efl_vpath_file_result_get(file_obj);
+
Eina_Bool int_ret = EINA_FALSE;
int_ret = efl_file_set(eo_super(obj, MY_CLASS), file, group);
if (!int_ret)
- return ret;
+ {
+eo_del(file_obj);
+return ret;
+ }
eed->program_scripts =
eina_hash_int32_new((Eina_Free_Cb)_edje_edit_program_script_free);
ef = eet_open(file, EET_FILE_MODE_READ);
+ eo_del(file_obj);
snprintf(buf, sizeof(buf), "edje/scripts/embryo/source/%i",
eed->base->collection->id);
diff --git a/src/lib/edje/edje_load.c b/src/lib/edje/edje_load.c
index e73007f..af9e7ce 100644
--- a/src/lib/edje/edje_load.c
+++ b/src/lib/edje/edje_load.c
@@ -246,11 +246,18 @@ edje_file_collection_list(const char *file)
Eina_List *lst;
if ((!file) || (!*file)) return NULL;
+ Efl_Vpath_File *file_obj =
+ efl_vpath_manager_fetch(EFL_VPATH_MANAGER_CLASS, file);
+ efl_vpath_file_do(file_obj);
+ // XXX:FIXME: allow this to be async
+ efl_vpath_file_wait(file_obj);
+ file = efl_vpath_file_result_get(file_obj);
f = eina_file_open(file, EINA_FALSE);
lst = edje_mmap_collection_list(f);
eina_file_close(f);
+ eo_del(file_obj);
return lst;
}
@@ -1412,11 +1419,6 @@ _edje_file_add(Edje *ed, const Eina_File *f)
ed->file = NULL;
}
}
- else
- {
-// FIXME: it will be actually better to remove ed->path.
-ed->path = eina_stringshare_add(eina_file_filename_get(f));
- }
}
static int
diff --git a/src/lib/edje/edje_private.h b/src/lib/edje/edje_private.h
index c70f282..92148e8 100644
--- a/src/lib/edje/edje_private.h
+++ b/src/lib/edje/edje_private.h
@@ -1660,6 +1660,8 @@ struct _Edje
doubleduration_scale;
+ Efl_Vpath_File *file_obj;
+
Eina_List*user_defined;
lua_State*L;
diff --git a/src/lib/edje/edje_smart.c b/src/lib/edje/edje_smart.c
index 2e905bf..ebfcf0c 100644
--- a/src/lib/edje/edje_smart.c
+++ b/src/lib/edje/edje_smart.c
@@ -50,6 +50,11 @@ _edje_object_eo_base_constructor(Eo *obj, Edje *ed)
EOLIAN static void
_edje_object_eo_base_destructor(Eo *obj, Edje *class_data)
{
+ if (class_data->file_obj)
+ {
+eo_del(class_data->file_obj);
+class_data->file_obj = NULL;
+ }
eo_destructor(eo_super(obj, MY_CLASS));
eo_data_unref(obj, class_data->base);
}
@@ -359,11 +364,28 @@ _edje_object_efl_file_file_set(Eo *obj, Edje *ed, const
char *file, const char *
ret = EINA_FALSE;
+ if (ed->file_obj)
+ {
+eo_del(ed->file_obj);
+ed->file_obj = NULL;
+ }
if (file)
{
-f = eina_file_open(file, EINA_FALSE);
+const char *file2;
+
+ed->file_obj = efl_vpath_manager_fetch(EFL_VPATH_MANAGER_CLASS, file);
+efl_vpath_file_do(ed->file_obj);
+// XXX:FIXME: allow this to be async
+efl_vpath_file_wait(ed->file_obj);
+file2 = efl_vpath_file_result_get(ed->file_obj);
+
+f = eina_file_open(file2, EINA_FALSE);
if (!f)
{
+ eo_del(ed->file_obj);
+ ed->file_obj = NULL;
+ if (ed->path) eina_stringshare_del(ed->path);
+ ed->path = NULL;
ed->load_error = EDJE_LOAD_ERROR_DOES_NOT_EXIST;
return ret;
}
@@ -371,7 +393,23 @@ _edje_object_efl_file_file_set(Eo *obj, Edje *ed, const
char *file, const char *
nested = eina_array_new(8);
if (_edje_object_file_set_internal(obj, f, group, NULL, NULL, nested))
- ret = EINA_TRUE;
+ {
+if (file)
+ {
+ ed->path = eina_stringshare_add(file);
+ }
+else
+ {
+ if (ed->path)
Re: [E-devel] Extra syntax plugins
On Tue, 24 Oct 2017 10:47:45 + Andrew Williams said: > Hi, > > Wiki time again. I was looking through and there are quite a lot of plugins > providing complex syntax features that don't seem to be used. The only time > that itemtable and exttab3 (both adding "features" to the table syntax) are > used is in our syntax documentation. > I propose removing these plugins as they are never used and add lots of > complexity making our syntax doc way more complex than it needs to be. i put those in because i actually expected them to be used by documentation in the future... be sure they are not used first. even then. removing them removes a tool that can be used. without some of the extended table stuff you can't put lists (like the sample) in a cell for example (from memory), which is very useful (not used atm but probably should be). it's also the only way to define cells with different backgrounds too. i guess having both is redundant perhaps. remove the more useless one then (itemtable)? but if this isn't being used for doc markdown... does it really matter? we still should have this for news, tutorials and all sorts of other stuff, unless you plan to convert the existing c primer, tutorials and doc pages there already to "non-dokuwiki markdown" ? > Any thoughts? > Andy > -- > http://andywilliams.me > http://ajwillia.ms > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- 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] Documentation into the Interfaces era :)
On Mon, 23 Oct 2017 11:57:56 + Andrew Williams said: > Hi, > > I will try to provide as much insight as I can: > > As many of the community are aware I started the Edi project to help get > people into coding on EFL - the learning curve is very steep and the > tooling was basically commandline based. Documentation is a big part of the > solution and we've come a long way both with the wiki and with the .eo > format for defining functionality. However this is set up to deliver only > on our website which a) is online and b) is external to the IDE. > To make a more integrated experience I started to think about how the > documentation could be more portable - so that it could be rendered in Edi > or other documentation browser online or offline, in the workflow of > someone's coding. Dokuwiki is a challenge here as the only renderer is the > dokuwiki web ui so reading the files off the filesystem is not really a > possibility without coding up a new render implementation. i was actually thinking of the docs always being online... :) then changes and improvements are immediately accessible to all users/devs ... :) yes yes. hard to refer to docs while on a plane ... i know. :) > A few conversations later and I was chatting to Cedric about what we can do > to make the documentation cleaner and he mentioned that Samsung was also > interested in this - and that they may be willing to finance some technical > writers to help. So he managed to get some professionals signed up and now > have people raring to go with documentation - but they don't know dokuwiki > and honestly I don't think that spending all day editing text files in a > browser window is the best way to write reams of documentation. A markup > format with external editors would mean higher productivity and also > increased portability. > > And so here we are. It looks like Markdown is a format that provides a lot > of additional benefits in terms of contributors, portability and future > proofing. ok. so here's a question. edi. how do you plan to display docs in edi? going to write a madkrown parser/formatter in "c" and then use textblocks (entries, efl.ui.text) to display? nothing else exists at the moment. or planning to add "markdown handling" directly to efl.ui.text/textblock etc. (like markup is supported)? going to write an "exporter" that uses the wiki php cod to parse markdown but instead of html - generate textblock etc. markup? > I hope that helps, > Andy > > On Sat, 21 Oct 2017 at 00:34 Carsten Haitzler wrote: > > > On Fri, 20 Oct 2017 08:06:00 +0900 Carsten Haitzler > > said: > > > > > On Thu, 19 Oct 2017 09:41:00 + Andrew Williams > > > > > said: > > > > > > > Hi, > > > > > > > > I see your point but I do not follow. There are various extensions of > > > > Markdown (PHP Markdown Extra is the one I mentioned which is very > > similar > > > > to GFM) some of them understand the concept of front matter and either > > try > > > > to parse it or ignore it. Some don't. Any Markdown editor that is GFM > > or > > > > Markdown Extra will be able to handle and live preview the rest of the > > > > content. > > > > > > > > This may not be 100% perfect in an external editor - but it mostly > > works > > > > well. With dokuwiki we have 0 external editors so 90% compatibility > > seems > > > > like a win, it's pretty easy to skip the front matter block when > > editing > > > > just like you would have to do when editing it on the website in the > > > > current format. > > > > > > So ... you are saying that it's not actually a universal standard. It's a > > > simpler core standard with extensions that are needed for our uses that > > may or > > > may not be supported by other tools etc., but you're going to rely on > > those > > > extensions to be supported for "interoperability"? Because I've been > > going off > > > the standards you point to (not extensions) that don't have the features > > as I > > > was indicating. > > > > I just had no insight into the decision to do this and am seeing > > inconsistencies and want to know the full why/what... > > > > > > Andrew > > > > > > > > On Thu, 19 Oct 2017 at 10:34 Carsten Haitzler > > wrote: > > > > > > > > > On Thu, 19 Oct 2017 09:28:16 + Andrew Williams < > > a...@andywilliams.me> > > > > > said: > > > > > &g
Re: [E-devel] EFL Docs missing
On Fri, 20 Oct 2017 12:46:30 + Andrew Williams said: > Hi. > > As I was going through some docs refactoring I found the > /docs/efl/index.txt contained links to many missing files: you mean /develop/efl/index.txt right? > * [[ecore_idle_exiters]] > * [[ecore_idle_enterers]] > * [[ecore_fd_handlers]] > * [[ecore_event_filters]] > * [[ecore_event_handlers]] > * [[ecore_timers]] > * [[ecore_animators]] > * [[ecore_jobs]] > * [[threads]] > * [[evas_rendering]] > > Does anyone have an idea what happened to these files? were they never > added or is it from a time when the programming guide and the docs were > intermingled? I think this was just a todo from memory ... the first ones were done... more still needed documenting. it was a "these are topics that need to be expanded on and explained". > Thanks, > Andy > -- > http://andywilliams.me > http://ajwillia.ms > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- 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] [EGIT] [website/www] master 02/06: MEDIUM: Update plugin folded to v2017-05-30
> >> var folded_hide = JSINFO['plugin_folded']['hide'];
> >>
> >> @@ -23,7 +24,7 @@ jQuery(function() {
> >> * toggle the folded element via className change also adjust the
> >> classname and
> >> * title tooltip on the folding link
> >> */
> >> -jQuery('.folder').click(function folded_toggle(evt) {
> >> +jQuery('.dokuwiki .folder').click(function folded_toggle(evt) {
> >> var id = this.href.match(/(#.*)$/)[1];
> >> var $id = jQuery(id);
> >>
> >> @@ -44,6 +45,46 @@ jQuery(function() {
> >> });
> >> });
> >>
> >> +function fold_unfold_all() {
> >> +var hide = -1;
> >> +var cpt = 1;
> >> +
> >> +var folders = document.getElementsByClassName("folder");
> >> +var i;
> >> +for (i = 0; i < folders.length; i++) {
> >> +// initially, find out whether we want to hide or unhide
> >> +if (hide == -1) {
> >> +if (folders[i].className.search("open") == -1) {
> >> +hide = 0;
> >> +} else {
> >> +hide = 1;
> >> +}
> >> +}
> >> +
> >> +if (hide == 1) {
> >> +folders[i].className = folders[i].className.replace(/open/g,
> >> "");
> >> +} else {
> >> +folders[i].className = folders[i].className + " open";
> >> +}
> >> +
> >> +}
> >> +
> >> +// get first folded_ object
> >> +var obj = document.getElementById("folded_" + cpt++);
> >> +while ( obj != null ) {
> >> +if (hide == 1) {
> >> +obj.className = obj.className.replace(/open/g, "");
> >> +obj.className = obj.className + " hidden";
> >> +} else {
> >> +obj.className = obj.className.replace(/hidden/g, "");
> >> +obj.className = obj.className + " open";
> >> +}
> >> +
> >> +// get next folded_ object
> >> +obj = document.getElementById("folded_" + cpt++);
> >> +}
> >> +}
> >> +
> >> // support graceful js degradation, this hides the folded blocks from
> >> view
> >> // before they are shown,
> >> // whilst still allowing non-js user to see any folded content.
> >> diff --git a/public_html/lib/plugins/folded/style.css
> >> b/public_html/lib/plugins/folded/style.css
> >> index e9533473..9c153134 100644
> >> --- a/public_html/lib/plugins/folded/style.css
> >> +++ b/public_html/lib/plugins/folded/style.css
> >> @@ -21,6 +21,28 @@ span.indicator {
> >> visibility: hidden;
> >> }
> >>
> >> +/* fold/unfold all button in pagetools area */
> >> +#dokuwiki__pagetools ul li a.fold_unfold_all {
> >> +background-position: right 0;
> >> +}
> >> +
> >> +#dokuwiki__pagetools ul li a.fold_unfold_all:before {
> >> +content: url(pagetools-close-open-sprite.png);
> >> +margin-top: 0;
> >> +}
> >> +
> >> +#dokuwiki__pagetools:hover ul li a.fold_unfold_all,
> >> +#dokuwiki__pagetools ul li a.fold_unfold_all:focus,
> >> +#dokuwiki__pagetools ul li a.fold_unfold_all:active {
> >> +background-image: url(pagetools-close-open-sprite.png);
> >> +}
> >> +
> >> +#dokuwiki__pagetools ul li a.fold_unfold_all:hover,
> >> +#dokuwiki__pagetools ul li a.fold_unfold_all:active,
> >> +#dokuwiki__pagetools ul li a.fold_unfold_all:focus {
> >> +background-position: right -45px;
> >> +}
> >> +
> >> /* below style rules are created by javascript
> >> .folded.hidden { display: none; }
> >> .folder span.indicator { visibility: visible; }
> >> diff --git a/public_html/lib/plugins/folded/syntax/div.php
> >> b/public_html/lib/plugins/folded/syntax/div.php
> >> index ae783227..b33b1f92 100644
> >> --- a/public_html/lib/plugins/folded/syntax/div.php
> >> +++ b/public_html/lib/plugins/folded/syntax/div.php
> >> @@ -8,9 +8,8 @@
> >> * @author Esther Brunner
> >> */
> >>
> >> -if(!defined('DOKU_INC'))
> >> define('DOKU_INC',realpath(dirname(__FILE__).'/../../').'/');
>
Re: [E-devel] EFL Docs missing
On Tue, 24 Oct 2017 13:49:03 + Andrew Williams said: > OK, thanks. > > the /develop link was /docs when I sent the email last week :) > Would it not be better to log TODO docs in phab rather than in the wiki? > Any objections to me removing dead links whilst we re-do the docs and > raising tickets for missing docs? i generally like my todo's where the todo is... like XXX: or FIXME: in code ... :) but ok - if you want > Cheers, > Andy > > On Tue, 24 Oct 2017 at 13:08 Carsten Haitzler wrote: > > > On Fri, 20 Oct 2017 12:46:30 + Andrew Williams > > said: > > > > > Hi. > > > > > > As I was going through some docs refactoring I found the > > > /docs/efl/index.txt contained links to many missing files: > > > > you mean /develop/efl/index.txt right? > > > > > * [[ecore_idle_exiters]] > > > * [[ecore_idle_enterers]] > > > * [[ecore_fd_handlers]] > > > * [[ecore_event_filters]] > > > * [[ecore_event_handlers]] > > > * [[ecore_timers]] > > > * [[ecore_animators]] > > > * [[ecore_jobs]] > > > * [[threads]] > > > * [[evas_rendering]] > > > > > > Does anyone have an idea what happened to these files? were they never > > > added or is it from a time when the programming guide and the docs were > > > intermingled? > > > > I think this was just a todo from memory ... the first ones were done... > > more > > still needed documenting. it was a "these are topics that need to be > > expanded > > on and explained". > > > > > Thanks, > > > Andy > > > -- > > > http://andywilliams.me > > > http://ajwillia.ms > > > > > -- > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > ___ > > > enlightenment-devel mailing list > > > enlightenment-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > -- > > - Codito, ergo sum - "I code, therefore I am" -- > > Carsten Haitzler - ras...@rasterman.com > > > > -- > http://andywilliams.me > http://ajwillia.ms -- - Codito, ergo sum - "I code, therefore I am" -- 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] EFL interfaces, pkg-config and headers
On Tue, 24 Oct 2017 13:04:27 -0400 Cedric Bail said: > Hello, > > As we are moving forward with EFL interfaces, it is becoming quite clear that > we should start to have one header and pkg-config for pure EFL interfaces > applications. The problem is that efl.pc and Efl.h are already taken. Going > with efl-2.pc, would kind of do it, but we don't have an associated libefl.so > for all our interfaces work and this will make it impossible to have later on > one library for all of efl. I am not to sure of what the solution should be > at the moment, but maybe efl-interfaces.pc that link with all of the efl > related library that are part of this work ? And which would provide a > Efl_Interfaces.h that include all the released new EFL API. Any though on > this ? well as marcel said - we have libefl.so and associated headers and so on... this defines the core interfaces and then other libs link (inherit) from this. this brings up again the whole topic of re-organizing our .so's and so on... without having a target for that and doing it it's a pain to answer the above. if we're going to do this then redoing build system to make it happen seems like a smart idea to me. i would leave autofoo as-is and then maybe add meson... and the meson build will structure output differently into fewer .so's and have compat symlinks installed. once that's complete we remove the autofoo build files and done. > 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 > -- - Codito, ergo sum - "I code, therefore I am" -- 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] GitFlow
7;t fear as HEAD can be pointed to develop instead of master if > >> > that's what folk are looking to have set up :) > >> > > >> > Cheers, > >> > Andrew > >> > > >> > -- > >> > http://andywilliams.me > >> > http://ajwillia.ms > >> > > >> -- > >> > 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 > >> > > -- > > http://andywilliams.me > > http://ajwillia.ms > > > -- > http://andywilliams.me > http://ajwillia.ms > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- 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] API docs
On Wed, 25 Oct 2017 17:09:06 + Andrew Williams said: > Hi, > > Today I was looking at the autogenerated EO docs... They seem to be quite C > specific - but they start with some great generic content. They also have > some clever autolink reference generation specific to c. So I got to originally the plan was to ensure things not covered by eo like eina properly got linked in just when putting the symbol anywhere in a doc anywhere on the wiki. the doc generator could generate links for things is knew about (eo methods/classes etc.). :) > thinking if we want to generate the API in multiple languages this script > would be the best place to do it. And so therefore I have landed on > mounting these docs in /develop/api so language specifics (such as ref/c) > can be handled within that space. indeed it was meant for multiple languages too. starting with c and well... we'll go from there. :) > As an outcome can raster or beber, or someone with local access to the wiki > VM please change a line of the local.conf? > > $conf['code_extn'] = 'develop/api/ref'; done. :) > Thanks :) > Andrew > -- > http://andywilliams.me > http://ajwillia.ms > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- 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] API docs
On Thu, 26 Oct 2017 08:54:26 +0900 Carsten Haitzler said: > On Wed, 25 Oct 2017 17:09:06 + Andrew Williams > said: > > > Hi, > > > > Today I was looking at the autogenerated EO docs... They seem to be quite C > > specific - but they start with some great generic content. They also have > > some clever autolink reference generation specific to c. So I got to > > originally the plan was to ensure things not covered by eo like eina properly > got linked in just when putting the symbol anywhere in a doc anywhere on the > wiki. the doc generator could generate links for things is knew about (eo > methods/classes etc.). :) > > > thinking if we want to generate the API in multiple languages this script > > would be the best place to do it. And so therefore I have landed on > > mounting these docs in /develop/api so language specifics (such as ref/c) > > can be handled within that space. > > indeed it was meant for multiple languages too. starting with c and well... > we'll go from there. :) > > > As an outcome can raster or beber, or someone with local access to the wiki > > VM please change a line of the local.conf? > > > > $conf['code_extn'] = 'develop/api/ref'; > > done. :) undone .. setting that makes all the pages stop marking down -> html and you get raw markdown text... hm... > > Thanks :) > > Andrew > > -- > > http://andywilliams.me > > http://ajwillia.ms > > -- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > 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 > -- - Codito, ergo sum - "I code, therefore I am" -- 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] GitFlow
On Thu, 26 Oct 2017 12:25:12 +0900 Jean-Philippe André said: > I fail to see why we wouldn't allow Andy & Co to test out this workflow on > EDI and use this as an experience? > Is it impossible to allow those branch names only on EDI's repo? I think I covered that with: "BUT if you really think it's so much better, try it on smaller projects first and show/prove it to be worth it". The general decision is to not change at this point ... except for the above from my recollection of the prior threads. So I thought it was clear already. > 2017-10-26 8:35 GMT+09:00 Carsten Haitzler : > > > On Wed, 25 Oct 2017 20:15:45 + Andrew Williams > > said: > > > > We had this discussion before in just one place I believe until you asked > > for > > specific branch names to be allowed. You wanted us to change how we branch > > and > > work with efl/e etc. the last time. I don't remember there being agreement > > with > > you on needing a change as I don't see our current model being bad or > > broken > > or causing trouble (discussion already had) vs gitflow. I don't know why > > you're > > bringing it back up as if there wasn't a consensus already. I believe the > > last > > discussion was roughly: > > > > "There is no agreement that any change is needed. The change you propose > > does > > nothing to actually improve anything by it's proposal. It just shuffles > > chairs, > > BUT if you really think it's so much better, try it on smaller projects > > first > > and show/prove it to be worth it". > > > > Or something to that effect. Most people were just silent on the topic. > > > > > Hi list, > > > > > > This conversation seems to have now happened in many places and it seems > > > that a few key individuals don't really see why we should be looking at > > > different branching models. I understand that opinion but if we don't try > > > new things then we will never be able to engage with new process or > > > technologies so I am keen to try gitflow nonetheless. > > > > > > So at this point I would like this thread to record a definitive > > decision. > > > Will we allow reduced branch name restrictions on our git repositories or > > > not? > > > Thanks, > > > Andy > > > > > > On Mon, 23 Oct 2017 at 11:43 Andrew Williams > > wrote: > > > > > > > Hi TAsn, > > > > > > > > Thanks for the reply. In gitflow these are the standards and they need > > to > > > > work across different users hence why having the developer namespace > > is not > > > > quite enough. Additionally the hotfix is not catered for in our current > > > > scheme (as I understand it). > > > > One nice thing with gitflow is the plugin that manages all the branches > > > > for you. If you have custom schemes then every person looking to take > > up > > > > development has to configure it before getting started, so the > > defaults are > > > > best if possible. > > > > > > > > I appreciate that consistency is important but taken so stringently it > > > > means we can never try anything new... An earlier discussion on > > GitFlow led > > > > to raster saying that he would need to see it working to understand the > > > > value - so I would like to do just that. > > > > > > > > I understand that folk don't necessarily see the value, but I have done > > > > and would like to try it for the projects that I am managing. That > > > > shouldn't be too onerous I think? Also as apps move from autotools to > > meson > > > > we already have a reduced consistency between projects. > > > > > > > > Thanks, > > > > Andy > > > > > > > > On Mon, 23 Oct 2017 at 11:34 Tom Hacohen wrote: > > > > > > > >> Heya, > > > >> > > > >> I don't quite understand what you are trying to do here. I mean, I > > > >> understand you are trying to have these, but what are these branches > > > >> for? If it's for you developing your own features why not put it in a > > > >> dev branch? > > > >> > > > >> We have these enforcements because we want to enforce branch names to > > > >> follow a consistent pattern across the repos. I don't mind changing it > > > >>
Re: [E-devel] API docs
On Thu, 26 Oct 2017 07:48:38 + Andrew Williams said: > Ouch. > > That marking up issue seems to have poisoned the cache for a few pages - > can someone with access to the server please reset the dokuwiki cache? it's the cache? really? u... odd... > Thanks, > Andy > > On Thu, 26 Oct 2017 at 02:57 Carsten Haitzler wrote: > > > On Thu, 26 Oct 2017 08:54:26 +0900 Carsten Haitzler > > said: > > > > > On Wed, 25 Oct 2017 17:09:06 + Andrew Williams > > > > > said: > > > > > > > Hi, > > > > > > > > Today I was looking at the autogenerated EO docs... They seem to be > > quite C > > > > specific - but they start with some great generic content. They also > > have > > > > some clever autolink reference generation specific to c. So I got to > > > > > > originally the plan was to ensure things not covered by eo like eina > > properly > > > got linked in just when putting the symbol anywhere in a doc anywhere on > > the > > > wiki. the doc generator could generate links for things is knew about (eo > > > methods/classes etc.). :) > > > > > > > thinking if we want to generate the API in multiple languages this > > script > > > > would be the best place to do it. And so therefore I have landed on > > > > mounting these docs in /develop/api so language specifics (such as > > ref/c) > > > > can be handled within that space. > > > > > > indeed it was meant for multiple languages too. starting with c and > > well... > > > we'll go from there. :) > > > > > > > As an outcome can raster or beber, or someone with local access to the > > wiki > > > > VM please change a line of the local.conf? > > > > > > > > $conf['code_extn'] = 'develop/api/ref'; > > > > > > done. :) > > > > undone .. setting that makes all the pages stop marking down -> html and > > you > > get raw markdown text... hm... > > > > > > Thanks :) > > > > Andrew > > > > -- > > > > http://andywilliams.me > > > > http://ajwillia.ms > > > > > > ------ > > > > Check out the vibrant tech community on one of the world's most > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > ___ > > > > enlightenment-devel mailing list > > > > enlightenment-devel@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > > -- > > > - Codito, ergo sum - "I code, therefore I am" -- > > > 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 > > > > > > > > > -- > > - Codito, ergo sum - "I code, therefore I am" -- > > 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 > > > -- > http://andywilliams.me > http://ajwillia.ms > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- 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] GitFlow
On Thu, 26 Oct 2017 07:19:51 + Andrew Williams said: > Hi, > > You are absolutely right - the “show it with a smaller project and prove > it’s worth is exactly why I brought it up. I was in the process of doing so > and hit this roadblock. No intention to beat a dead horse - I actually > thought I was doing what was agreed. > > Apologies if I got the wrong end of the stick. Well I think doing this with edi is fine. is it possible to have just edi have different branch naming schemes? i don't know. if it's not then we have problems. but i think we;re on the same page atm "try this in a smaller scale and show it improves things - us that to convince everyone else". :) > Andy > > On Thu, 26 Oct 2017 at 00:58, Carsten Haitzler wrote: > > > On Wed, 25 Oct 2017 20:15:45 + Andrew Williams > > said: > > > > We had this discussion before in just one place I believe until you asked > > for > > specific branch names to be allowed. You wanted us to change how we branch > > and > > work with efl/e etc. the last time. I don't remember there being agreement > > with > > you on needing a change as I don't see our current model being bad or > > broken > > or causing trouble (discussion already had) vs gitflow. I don't know why > > you're > > bringing it back up as if there wasn't a consensus already. I believe the > > last > > discussion was roughly: > > > > "There is no agreement that any change is needed. The change you propose > > does > > nothing to actually improve anything by it's proposal. It just shuffles > > chairs, > > BUT if you really think it's so much better, try it on smaller projects > > first > > and show/prove it to be worth it". > > > > Or something to that effect. Most people were just silent on the topic. > > > > > Hi list, > > > > > > This conversation seems to have now happened in many places and it seems > > > that a few key individuals don't really see why we should be looking at > > > different branching models. I understand that opinion but if we don't try > > > new things then we will never be able to engage with new process or > > > technologies so I am keen to try gitflow nonetheless. > > > > > > So at this point I would like this thread to record a definitive > > decision. > > > Will we allow reduced branch name restrictions on our git repositories or > > > not? > > > Thanks, > > > Andy > > > > > > On Mon, 23 Oct 2017 at 11:43 Andrew Williams > > wrote: > > > > > > > Hi TAsn, > > > > > > > > Thanks for the reply. In gitflow these are the standards and they need > > to > > > > work across different users hence why having the developer namespace > > is not > > > > quite enough. Additionally the hotfix is not catered for in our current > > > > scheme (as I understand it). > > > > One nice thing with gitflow is the plugin that manages all the branches > > > > for you. If you have custom schemes then every person looking to take > > up > > > > development has to configure it before getting started, so the > > defaults are > > > > best if possible. > > > > > > > > I appreciate that consistency is important but taken so stringently it > > > > means we can never try anything new... An earlier discussion on > > GitFlow led > > > > to raster saying that he would need to see it working to understand the > > > > value - so I would like to do just that. > > > > > > > > I understand that folk don't necessarily see the value, but I have done > > > > and would like to try it for the projects that I am managing. That > > > > shouldn't be too onerous I think? Also as apps move from autotools to > > meson > > > > we already have a reduced consistency between projects. > > > > > > > > Thanks, > > > > Andy > > > > > > > > On Mon, 23 Oct 2017 at 11:34 Tom Hacohen wrote: > > > > > > > >> Heya, > > > >> > > > >> I don't quite understand what you are trying to do here. I mean, I > > > >> understand you are trying to have these, but what are these branches > > > >> for? If it's for you developing your own features why not put it in a > > > >> dev branch? > > > >> > > > >> We hav
Re: [E-devel] API docs
On Thu, 26 Oct 2017 07:48:38 + Andrew Williams said: > Ouch. > > That marking up issue seems to have poisoned the cache for a few pages - > can someone with access to the server please reset the dokuwiki cache? it's not the cache... i wiped that... it's something else going wrong. aaargh! > Thanks, > Andy > > On Thu, 26 Oct 2017 at 02:57 Carsten Haitzler wrote: > > > On Thu, 26 Oct 2017 08:54:26 +0900 Carsten Haitzler > > said: > > > > > On Wed, 25 Oct 2017 17:09:06 + Andrew Williams > > > > > said: > > > > > > > Hi, > > > > > > > > Today I was looking at the autogenerated EO docs... They seem to be > > quite C > > > > specific - but they start with some great generic content. They also > > have > > > > some clever autolink reference generation specific to c. So I got to > > > > > > originally the plan was to ensure things not covered by eo like eina > > properly > > > got linked in just when putting the symbol anywhere in a doc anywhere on > > the > > > wiki. the doc generator could generate links for things is knew about (eo > > > methods/classes etc.). :) > > > > > > > thinking if we want to generate the API in multiple languages this > > script > > > > would be the best place to do it. And so therefore I have landed on > > > > mounting these docs in /develop/api so language specifics (such as > > ref/c) > > > > can be handled within that space. > > > > > > indeed it was meant for multiple languages too. starting with c and > > well... > > > we'll go from there. :) > > > > > > > As an outcome can raster or beber, or someone with local access to the > > wiki > > > > VM please change a line of the local.conf? > > > > > > > > $conf['code_extn'] = 'develop/api/ref'; > > > > > > done. :) > > > > undone .. setting that makes all the pages stop marking down -> html and > > you > > get raw markdown text... hm... > > > > > > Thanks :) > > > > Andrew > > > > -- > > > > http://andywilliams.me > > > > http://ajwillia.ms > > > > > > ------ > > > > Check out the vibrant tech community on one of the world's most > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > ___ > > > > enlightenment-devel mailing list > > > > enlightenment-devel@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > > -- > > > - Codito, ergo sum - "I code, therefore I am" -- > > > 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 > > > > > > > > > -- > > - Codito, ergo sum - "I code, therefore I am" -- > > 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 > > > -- > http://andywilliams.me > http://ajwillia.ms > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- 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] GitFlow
On Thu, 26 Oct 2017 17:35:39 +0100 Tom Hacohen said: > Intended to be would maybe be more appropriate, and then the statement > would still apply. With that being said, I'm sorry to hear that it has > changed, you guys should be spanking b0rokers more, don't let them > win. > > Regardless of that, as said on IRC, the reason why we do trunk > (master) based development is that we all run master all the time and > thus test as many configurations as possible all the time. I don't see > why we need a rolling-branch that is more stable (master in the > gitflow terminology) than the development trunk, because we'll all > just switch to develop and that's it. This was my thought too. we all switch and ADD the work of having to cherrypick/merge patches from develop (and deal with conflicts and whatever) to master(stable) AND now almost no developers use master/stable anymore so this gets little to no testing. > Andy claims that there are compelling cases. I've read some blog posts > over the years about it, and I'm not convinced. > > -- > Tom. > > > On Thu, Oct 26, 2017 at 5:14 PM, Mike Blumenkrantz > wrote: > > 'Our master is already considered "stable" and in a release state, so it > > really doesn't match our workflow.' > > > > Things have changed a bit since you've been gone, and this is not even > > remotely close to being true anymore. As far as all of my use cases go > > (everyday use on X, testing on Wayland, basic application functionality), > > master has been completely unusable for this entire release cycle. Based on > > the current workflow of write code -> commit directly to master without any > > form of testing, it seems like this will continue to be the case for the > > foreseeable future. > > > > I am in no way directing this at you personally, but for us to be basing > > any decision on the above statement is, at this time, nothing more than a > > false premise (https://en.wikipedia.org/wiki/False_premise) argument. > > > > On Thu, Oct 26, 2017 at 8:39 AM Tom Hacohen wrote: > > > >> I accidentally hit send, didn't mean to. > >> Here is my full reply: > >> It's possible, yes, but it doesn't address my initial concerns, which > >> are that edi will stick out compared to the other e projects. This > >> will be considered a success by you for sure, and I don't see us > >> changing the efl to follow, so it'll stay different. > >> Furthermore, once you publish a tag/branch they should remain there, > >> so even if we don't like it, it'll have to stay in edi or at least edi > >> will be different. > >> Btw, changing HEAD to be "develop" rather than "master" is a bit more > >> intrusive and painful. > >> > >> Additionally, I just took a look at this gitflow thing, and noticed > >> that it's pretty much what we do but worse (apart of the poor mistake > >> that we did which is having the stable branches be named per repo > >> rather than having a consistent name, that is, efl-1.7 instead of > >> stable-1.17). > >> We never needed a "hotfix" branch, the "release" branch has always > >> proved sufficient for us (I can see the potential need, we just never > >> hit it). After taking a second look, he deletes branches afterwards, > >> so it's a workflow we can and already do here. > >> Release branches we already have. > >> We name our tags v1.17.0 compared to 1.17.0 which I think is better. > >> I don't see the advantage of having a "develop" branch in addition to > >> master given our workflow. Our master is already considered "stable" > >> and in a release state, so it really doesn't match our workflow. > >> > >> So I'm not really impressed with this suggestion (and in particular > >> GitFlow), and I don't think it can be done in a way that is possible > >> to revert or is compatible with what we do. > >> As I said, if you want to test it, test it with your own dev branches, > >> show us that the workflow works and just configure your tools for this > >> testing period, I don't see why the test period needs to have the > >> formal names. > >> > >> You mentioned having tools that work with it, what exactly? > >> > >> As a side note, I'm OK with changing the stable release branches to > >> "release-x.y" if people are OK with that, instead of the per repo > >> naming, thi
Re: [E-devel] GitFlow
On Thu, 26 Oct 2017 16:14:14 + Mike Blumenkrantz said: > 'Our master is already considered "stable" and in a release state, so it > really doesn't match our workflow.' > > Things have changed a bit since you've been gone, and this is not even > remotely close to being true anymore. As far as all of my use cases go > (everyday use on X, testing on Wayland, basic application functionality), > master has been completely unusable for this entire release cycle. Based on > the current workflow of write code -> commit directly to master without any > form of testing, it seems like this will continue to be the case for the > foreseeable future. i think we have 2 artefacts of our current state: 1. wayland work is still ongoing and in flux. it will settle down eventually 2. eo/interfaces work is very invasive and is going to be creating little hiccups all over. when these 2 settle down it'll be back to normal. the INTENT is for master to be changing and of course have little issues here and there BUT to be usable day to day. the idea is that you write new code and test before it goes into master and/or when you do land changes you are around to fix them ASAP so the instability is very transient. that's the intent, point and it is actually how svn and cvs worked for over a decade. > I am in no way directing this at you personally, but for us to be basing > any decision on the above statement is, at this time, nothing more than a > false premise (https://en.wikipedia.org/wiki/False_premise) argument. > > On Thu, Oct 26, 2017 at 8:39 AM Tom Hacohen wrote: > > > I accidentally hit send, didn't mean to. > > Here is my full reply: > > It's possible, yes, but it doesn't address my initial concerns, which > > are that edi will stick out compared to the other e projects. This > > will be considered a success by you for sure, and I don't see us > > changing the efl to follow, so it'll stay different. > > Furthermore, once you publish a tag/branch they should remain there, > > so even if we don't like it, it'll have to stay in edi or at least edi > > will be different. > > Btw, changing HEAD to be "develop" rather than "master" is a bit more > > intrusive and painful. > > > > Additionally, I just took a look at this gitflow thing, and noticed > > that it's pretty much what we do but worse (apart of the poor mistake > > that we did which is having the stable branches be named per repo > > rather than having a consistent name, that is, efl-1.7 instead of > > stable-1.17). > > We never needed a "hotfix" branch, the "release" branch has always > > proved sufficient for us (I can see the potential need, we just never > > hit it). After taking a second look, he deletes branches afterwards, > > so it's a workflow we can and already do here. > > Release branches we already have. > > We name our tags v1.17.0 compared to 1.17.0 which I think is better. > > I don't see the advantage of having a "develop" branch in addition to > > master given our workflow. Our master is already considered "stable" > > and in a release state, so it really doesn't match our workflow. > > > > So I'm not really impressed with this suggestion (and in particular > > GitFlow), and I don't think it can be done in a way that is possible > > to revert or is compatible with what we do. > > As I said, if you want to test it, test it with your own dev branches, > > show us that the workflow works and just configure your tools for this > > testing period, I don't see why the test period needs to have the > > formal names. > > > > You mentioned having tools that work with it, what exactly? > > > > As a side note, I'm OK with changing the stable release branches to > > "release-x.y" if people are OK with that, instead of the per repo > > naming, this will make it slightly more compatible for you, and > > actually makes sense regardless (was a mistake in the first place). > > > > -- > > Tom > > > > On Thu, Oct 26, 2017 at 1:20 PM, Tom Hacohen wrote: > > > It is possible, yes. > > > > > > On Thu, Oct 26, 2017 at 10:50 AM, Carsten Haitzler > > wrote: > > >> On Thu, 26 Oct 2017 07:19:51 + Andrew Williams < > > a...@andywilliams.me> said: > > >> > > >>> Hi, > > >>> > > >>> You are absolutely right - the “show it with a smaller project and > > prove > > >>> it’s worth is exactly why I brought it up. I was in th
Re: [E-devel] GitFlow
On Thu, 26 Oct 2017 13:38:12 +0100 Tom Hacohen said: > I accidentally hit send, didn't mean to. > Here is my full reply: > It's possible, yes, but it doesn't address my initial concerns, which > are that edi will stick out compared to the other e projects. This > will be considered a success by you for sure, and I don't see us > changing the efl to follow, so it'll stay different. > Furthermore, once you publish a tag/branch they should remain there, > so even if we don't like it, it'll have to stay in edi or at least edi > will be different. > Btw, changing HEAD to be "develop" rather than "master" is a bit more > intrusive and painful. > > Additionally, I just took a look at this gitflow thing, and noticed > that it's pretty much what we do but worse (apart of the poor mistake > that we did which is having the stable branches be named per repo > rather than having a consistent name, that is, efl-1.7 instead of > stable-1.17). yeah. this is really my only gripe with what we do. stable-xxx or release-xxx or rel-xxx or ver-xxx would have been just fine and easier to deal with. > We never needed a "hotfix" branch, the "release" branch has always > proved sufficient for us (I can see the potential need, we just never > hit it). After taking a second look, he deletes branches afterwards, > so it's a workflow we can and already do here. > Release branches we already have. > We name our tags v1.17.0 compared to 1.17.0 which I think is better. > I don't see the advantage of having a "develop" branch in addition to > master given our workflow. Our master is already considered "stable" > and in a release state, so it really doesn't match our workflow. > > So I'm not really impressed with this suggestion (and in particular > GitFlow), and I don't think it can be done in a way that is possible > to revert or is compatible with what we do. > As I said, if you want to test it, test it with your own dev branches, > show us that the workflow works and just configure your tools for this > testing period, I don't see why the test period needs to have the > formal names. > > You mentioned having tools that work with it, what exactly? > > As a side note, I'm OK with changing the stable release branches to > "release-x.y" if people are OK with that, instead of the per repo > naming, this will make it slightly more compatible for you, and > actually makes sense regardless (was a mistake in the first place). it'd make for a not so nice history though... releases older than X are a different naming scheme for the branches, but i guess it's a hiccup we'd have to live with for such a change. > -- > Tom > > On Thu, Oct 26, 2017 at 1:20 PM, Tom Hacohen wrote: > > It is possible, yes. > > > > On Thu, Oct 26, 2017 at 10:50 AM, Carsten Haitzler > > wrote: > >> On Thu, 26 Oct 2017 07:19:51 + Andrew Williams > >> said: > >> > >>> Hi, > >>> > >>> You are absolutely right - the “show it with a smaller project and prove > >>> it’s worth is exactly why I brought it up. I was in the process of doing > >>> so and hit this roadblock. No intention to beat a dead horse - I actually > >>> thought I was doing what was agreed. > >>> > >>> Apologies if I got the wrong end of the stick. > >> > >> Well I think doing this with edi is fine. is it possible to have just edi > >> have different branch naming schemes? i don't know. if it's not then we > >> have problems. but i think we;re on the same page atm "try this in a > >> smaller scale and show it improves things - us that to convince everyone > >> else". :) > >> > >>> Andy > >>> > >>> On Thu, 26 Oct 2017 at 00:58, Carsten Haitzler > >>> wrote: > >>> > >>> > On Wed, 25 Oct 2017 20:15:45 + Andrew Williams > >>> > said: > >>> > > >>> > We had this discussion before in just one place I believe until you > >>> > asked for > >>> > specific branch names to be allowed. You wanted us to change how we > >>> > branch and > >>> > work with efl/e etc. the last time. I don't remember there being > >>> > agreement with > >>> > you on needing a change as I don't see our current model being bad or > >>> > broken > >>> > or causing trouble (discussion already had) vs gitflow. I don't know why > >>> > you
Re: [E-devel] Enlightenment DR 0.22.0-beta Release
On Thu, 26 Oct 2017 14:29:36 + Mike Blumenkrantz said: actually settings -> extensions -> shelves lets you access all the core shelf config (size, positioning, fill screen edge or not, content). the only thing you can't do is move gadgets around within a shelf without a right mouse. i guess a long-press would be good to add for bringing up menus... > Then, if it's a single-finger only device the user will face the same > problems they had with a shelf--ideally a profile will be available which > suits the user's taste--or they will rebind right click (two finger click) > to trigger the menu action. > > On Mon, Oct 23, 2017 at 7:45 PM Carsten Haitzler > wrote: > > > On Mon, 23 Oct 2017 12:13:27 + Mike Blumenkrantz > > said: > > > > > The resize with ctrl+wheel is added by default as a regular mouse binding > > > which can be modified or changed as necessary by the user. Modern laptops > > > have a thumbscroll available on the touchpad; this has been the case for > > a > > > number of years. > > > > what if you have a touchscreen only device... that doesn't have a mouse at > > all > > (no touchpad or even thinkpad nub thing). ? :) > > > > > On Mon, Oct 23, 2017 at 6:50 AM Quelrond wrote: > > > > > > > On 23/10/2017 12:36, Mike Blumenkrantz wrote: > > > > > Thanks for your interest and feedback regarding this recent release. > > > > > > > > > > 1. Please file a ticket at https://phab.enlightenment.org/maniphest/ > > > > Thanks for your answer, I'll file the 3 tickets this evening. > > > > > 2. This is adjustable using ctrl+wheel similar to browser > > magnification > > > > You are really cool, guys!! It works, but... what if I have no wheel? > > ;) > > > > Normally, on a laptop one have just a touchpad with buttons... > > > > BTW, with a correct size of the bryce on my 14" laptop, the blue line > > on > > > > the luncher bar, indicating the running apps, is too small, almost > > > > invisible... > > > > > > > > > > > > Peter > > > > > > > > > 3. Please file a ticket at https://phab.enlightenment.org/maniphest/ > > > > > 4. Please file a ticket at https://phab.enlightenment.org/maniphest/ > > > > > > > > > > > > > > > On Sat, Oct 21, 2017 at 4:57 PM Quelrond wrote: > > > > > > > > > >> Hi, > > > > >> > > > > >> I've just updated EFL (to 1.20.5 release) and Enlightenment (to > > > > >> 0.22.0-beta) on my FreeBSD 11 laptop. > > > > >> > > > > >> 1. I could crash it, moving bryce gadgets (note that in the same > > time I > > > > >> was building a large project in terminology, the CPU was really > > high). > > > > >> I've got the backtrace (the images attached). > > > > >> > > > > >> 2. I cannot change the size of bryce. Actually it has the horizontal > > > > >> orientation, I would like to decrease his height. Is it possible? > > > > >> > > > > >> 3. I cannot understand how to use enlightenment_askpass tool. I > > would > > > > >> like to use it with sudo to start some GUI apps with root > > privileges. > > > > >> > > > > >> 4. CPUFreq gadget moves his arrow in the opposite direction - when > > the > > > > >> frequency is max the arrow is glued to the left-button edge, when > > the > > > > >> frequency is decreasing (I can see the digits changing inside the > > shelf > > > > >> gadget) the arrow begins to move to the top-right. > > > > >> > > > > >> It seems that the overall performance is improved, comparing with > > E21. > > > > >> I'm using E on the everyday basis, so I'll report my impressions > > about > > > > >> the stability a little bit later ;) > > > > >> > > > > >> > > > > >> Thank you for this release > > > > >> > > > > >> Peter > > > > >> > > > > >> > > > > >> > > > > >> On 29/09/2017 19:48, Mike Blumenkrantz wrote: > > > > >>> HIGHLIGHTS > > > > >>> * Greatly improved Wayland support > > > > >>> * Improvements to new gadget
Re: [E-devel] GitFlow
6, 2017 at 8:39 AM Tom Hacohen wrote: > > > > > > > >> I accidentally hit send, didn't mean to. > > > >> Here is my full reply: > > > >> It's possible, yes, but it doesn't address my initial concerns, which > > > >> are that edi will stick out compared to the other e projects. This > > > >> will be considered a success by you for sure, and I don't see us > > > >> changing the efl to follow, so it'll stay different. > > > >> Furthermore, once you publish a tag/branch they should remain there, > > > >> so even if we don't like it, it'll have to stay in edi or at least edi > > > >> will be different. > > > >> Btw, changing HEAD to be "develop" rather than "master" is a bit more > > > >> intrusive and painful. > > > >> > > > >> Additionally, I just took a look at this gitflow thing, and noticed > > > >> that it's pretty much what we do but worse (apart of the poor mistake > > > >> that we did which is having the stable branches be named per repo > > > >> rather than having a consistent name, that is, efl-1.7 instead of > > > >> stable-1.17). > > > >> We never needed a "hotfix" branch, the "release" branch has always > > > >> proved sufficient for us (I can see the potential need, we just never > > > >> hit it). After taking a second look, he deletes branches afterwards, > > > >> so it's a workflow we can and already do here. > > > >> Release branches we already have. > > > >> We name our tags v1.17.0 compared to 1.17.0 which I think is better. > > > >> I don't see the advantage of having a "develop" branch in addition to > > > >> master given our workflow. Our master is already considered "stable" > > > >> and in a release state, so it really doesn't match our workflow. > > > >> > > > >> So I'm not really impressed with this suggestion (and in particular > > > >> GitFlow), and I don't think it can be done in a way that is possible > > > >> to revert or is compatible with what we do. > > > >> As I said, if you want to test it, test it with your own dev branches, > > > >> show us that the workflow works and just configure your tools for this > > > >> testing period, I don't see why the test period needs to have the > > > >> formal names. > > > >> > > > >> You mentioned having tools that work with it, what exactly? > > > >> > > > >> As a side note, I'm OK with changing the stable release branches to > > > >> "release-x.y" if people are OK with that, instead of the per repo > > > >> naming, this will make it slightly more compatible for you, and > > > >> actually makes sense regardless (was a mistake in the first place). > > > >> > > > >> -- > > > >> Tom > > > >> > > > >> On Thu, Oct 26, 2017 at 1:20 PM, Tom Hacohen wrote: > > > >> > It is possible, yes. > > > >> > > > > >> > On Thu, Oct 26, 2017 at 10:50 AM, Carsten Haitzler < > > > ras...@rasterman.com> > > > >> wrote: > > > >> >> On Thu, 26 Oct 2017 07:19:51 + Andrew Williams < > > > >> a...@andywilliams.me> said: > > > >> >> > > > >> >>> Hi, > > > >> >>> > > > >> >>> You are absolutely right - the “show it with a smaller project and > > > >> prove > > > >> >>> it’s worth is exactly why I brought it up. I was in the process of > > > >> doing so > > > >> >>> and hit this roadblock. No intention to beat a dead horse - I > > > actually > > > >> >>> thought I was doing what was agreed. > > > >> >>> > > > >> >>> Apologies if I got the wrong end of the stick. > > > >> >> > > > >> >> Well I think doing this with edi is fine. is it possible to have > > > >> >> just > > > >> edi have > > > >> >> different branch naming schemes? i don't know. if it's not then we > > > have > > > >> >> problems. but i think we;re on th
Re: [E-devel] A complete non-legacy documentation
On Fri, 27 Oct 2017 09:29:21 + Andrew Williams said: > Hi, > > I have realised today that as we move away from the legacy APIs and the > doxygen they contain to a pure eo interfaces approach (as at > https://www.enlightenment.org/develop/api/) we are not covering eina_ or > eo_ (with the exception of a few types that are referenced). yup. i know. :) this is one of those "what will we do?" things. this needs documenting of course. how? good q. > Has anyone figured a strategy for making sure that eina's fundamental > underpinnings of our interfaces get included in the documentation we are > generating? Apologies if this is in progress or planned but I don't recall > it being discussed recently so wonder if there is a hole in our current > approach. > > Thanks, > Andy > -- > http://andywilliams.me > http://ajwillia.ms > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- 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] User Stories
On Fri, 27 Oct 2017 09:24:42 + Andrew Williams said: > Hi, > > Cheers for that but from a documentation point of view we're looking more > to explore how and why which types of developers might be wanting to > engage. Rather than an example app list we are trying to gather something > more like personas or motivations, perhaps along the lines of: > > *) Experienced C developer looking to make use of the advanced graphics > functions available through EFL > *) First time software engineer starting with C and EFL looks like a great > way to get something pretty running > *) Enterprise organisation management says that EFL has been specified and > I need to know exactly how to get audio and AI related APIs working for my > embedded system I frankly don't have a target audience... well more specifically the C api is going to have a specific target. other bindings might have other targets... are we just talking c api? > For example. > Do we have a concept of our target audience in these terms? > > Thanks, > Andy > > On Thu, 19 Oct 2017 at 02:27 Carsten Haitzler wrote: > > > On Wed, 18 Oct 2017 14:36:07 + Andrew Williams > > said: > > > > > Hi all, > > > > > > One of the items summarised from our Malta chats earlier this year was: > > > "As a community we want to enable great apps to work consistently on a > > wide > > > variety of platforms (device and modality) but we currently don't have a > > > roadmap of how to get there. Additional support would be needed esp. in > > the > > > higher level APIs to do this" > > > > > > Now we're looking at getting documentation in place to help with this > > > mission it's become clear that we are not completely aligned on the types > > > of thing we should be focusing on guiding developers through. > > > Would it be possible to work through a couple of user stories or journeys > > > that we can organise in priority order so we know we're hitting the top > > > score items first? > > > > > > Any suggestions on what is most important to us or to the developers we > > > wish to entice? :) > > > > ummm well hello world, then a set of simple apps (ok/cancel dialogs, list > > of > > items to select something from, getting more and more involved). maybe pick > > things that have some "boom" like "make your own video player", "make your > > own > > music player", note taking app, todo list app. really just simple ones not > > very involved maybe? just thoughts. > > > > -- > > - Codito, ergo sum - "I code, therefore I am" -- > > Carsten Haitzler - ras...@rasterman.com > > > > -- > http://andywilliams.me > http://ajwillia.ms -- - Codito, ergo sum - "I code, therefore I am" -- 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] GitFlow
On Fri, 27 Oct 2017 14:32:40 + Mike Blumenkrantz said: > On Thu, Oct 26, 2017 at 8:27 PM Carsten Haitzler > wrote: > > > On Thu, 26 Oct 2017 19:02:58 +0200 marcel-hollerb...@t-online.de said: > > > > > Two things, > > > > > > Calling efl-master unmanagable and unrunable is just spreading a > > > apocalyptic mood and does not really tell what is going on. There are > > > > I absolutely agree. I and many others use master all day every day. For > > wayland > > work it has issues and That is specific to that set of code. Sometimes eo > > work > > disrupts something. But it gets fixed. > > > > > bugs and a few crashes, yes, but the same happened a few years back when > > > i started with efl stuff. (Also, how can you call efl master unstable if > > > you havnt run it in a long time ? :D) > > > > Ooooh. nice catch there. :) > > > > It is indeed inconceivable that I could have periodically tested master, > found it unusable each time, and then gone back to using stable. You've > certainly caught me; well done everyone, and thanks for your hard work in > keeping this mailing list so honest. Let's wrap it up and call it a /thread. You did say exactly: "I haven't run efl master in a long time". That precludes testing as that would be running. Marcel makes a very very very good point. If you claim you have not run it for a very long time, does any evaluation of stability or correctness matter? > > > I guess you are refering to enlightenment when writing > > > > Well actually enlightenment is the far worse offender. It actively chooses > > to > > crash instead of recover. I had a fight with mike about this when i was > > left > > trying to resize a window and every time I did it E crashed. I could never > > resize it. It literally was unusable by explicit CHOICE to crash instead of > > log and move on. > > > > EFL and E policy has always been to be defensive and recover as much as > > possible at all times. Just look at the code with all the magic/eoid, null > > checks and more. > > As a result I received a bug report about this issue and it was resolved, > unlike the current behavior with other EFL-based apps where they just throw > errors, nobody reports them, and master continually regresses to function > worse than the previous release. I'm completely fine with annoying users of > development builds in order to force them to report bugs. If it becomes > intolerable for you then you should be running a release build since that's > what they're for. And yet when you get annoyed by EFL causing you problems that are not nearly as bad you claim it's unusable? Where a bug in EFL in unintentional, your decision to crash is intentional. I'm trying to point out a double standard here. In fact extra worse. First a "Well it's so bad I just don't use it anymore and haven't in a long time" == "I don't want to help or work with EFL development" and in addition: "But hey - anyone who uses E which I work on has to deal with crashes and unsalability by design and that's fine, but I will not tolerate it from EFL where it's unintentional" ? That's what it comes off as. Now if efl is "unusable" is entirely debatable. At least 2 people here disagree with you on that. I use it all day, every day this way and I do not see what you are complaining about. > > > "current workflow of write code -> commit directly to master without any > > > form of testing". I try to test my changes before in enlightenment > > > before commiting something, but do you really expect a dev that pushes a > > > commit to start every single window / setting in e ? Test every single > > > configuration before committing anything ?! Thats not really doable, and > > > as long as there is no automated testsuite noone will ever start to do > > > that. > > > > Indeed the last bit here is the positive part. If we want to make it > > harder to > > break things, having more tests is what we need. Mike - I know you have > > worked > > on some e test stuff. If it's ready for people to use, then perhaps a mail > > about it and docs on how to use it to catch errors would be good. > > Something not > > too invasive (can be run in a window for example which I believe it can > > be... ? > > ). > > > > It has been (and continues to be) completely functional in all engines > since this past March, but I gave up on it within a month or two since > constant EFL regressions made getting even a baseline set of correc
Re: [E-devel] Documentation into the Interfaces era :)
On Tue, 24 Oct 2017 13:39:14 + Andrew Williams said:
> On Tue, 24 Oct 2017 at 13:09 Carsten Haitzler wrote:
>
> > On Mon, 23 Oct 2017 11:57:56 + Andrew Williams
> > said:
> >
> > > Hi,
> > >
> > > I will try to provide as much insight as I can:
> > >
> > > As many of the community are aware I started the Edi project to help get
> > > people into coding on EFL - the learning curve is very steep and the
> > > tooling was basically commandline based. Documentation is a big part of
> > the
> > > solution and we've come a long way both with the wiki and with the .eo
> > > format for defining functionality. However this is set up to deliver only
> > > on our website which a) is online and b) is external to the IDE.
> > > To make a more integrated experience I started to think about how the
> > > documentation could be more portable - so that it could be rendered in
> > Edi
> > > or other documentation browser online or offline, in the workflow of
> > > someone's coding. Dokuwiki is a challenge here as the only renderer is
> > the
> > > dokuwiki web ui so reading the files off the filesystem is not really a
> > > possibility without coding up a new render implementation.
> >
> > i was actually thinking of the docs always being online... :) then changes
> > and
> > improvements are immediately accessible to all users/devs ... :) yes yes.
> > hard
> > to refer to docs while on a plane ... i know. :)
> >
>
> In it's current form not only do you have to be online you have to have a
> browser window open alongside your code. To be worried about immediate
> propagation of improvements implies a lot more documentation activity than
> we see - and once the API has a solid release would important changes to
> them not be less common?
>
> > A few conversations later and I was chatting to Cedric about what we can
> > do
> > > to make the documentation cleaner and he mentioned that Samsung was also
> > > interested in this - and that they may be willing to finance some
> > technical
> > > writers to help. So he managed to get some professionals signed up and
> > now
> > > have people raring to go with documentation - but they don't know
> > dokuwiki
> > > and honestly I don't think that spending all day editing text files in a
> > > browser window is the best way to write reams of documentation. A markup
> > > format with external editors would mean higher productivity and also
> > > increased portability.
> > >
> > > And so here we are. It looks like Markdown is a format that provides a
> > lot
> > > of additional benefits in terms of contributors, portability and future
> > > proofing.
> >
> > ok. so here's a question. edi. how do you plan to display docs in edi?
> > going to
> > write a madkrown parser/formatter in "c" and then use textblocks (entries,
> > efl.ui.text) to display? nothing else exists at the moment. or planning to
> > add
> > "markdown handling" directly to efl.ui.text/textblock etc. (like markup is
> > supported)? going to write an "exporter" that uses the wiki php cod to
> > parse
> > markdown but instead of html - generate textblock etc. markup?
> >
>
> Ideally we would have a native markdown component for speed purpose - it
> would make a nice editor as well as a way to view the docs and dynamically
> link in context.
> However that is a reasonable amount of work - due to the commonality of
> this format we can get there faster by using a pre-built parser, hooking in
> whatever clever linking we want and preview through something currently
> available like HTML. Not the perfect solution but much quicker to get
> working.
>
> > I hope that helps,
> > > Andy
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am" --
> > Carsten Haitzler - ras...@rasterman.com
>
>
> Not sure if that helps with the context you were looking for?
> Andy
more context.
but if you want files for docs inside something like edi shouldn't they have far
more semantic info -not markdown? like literally something like:
class colors {
property {
name: color
modes: RW
type: int r (0-255), int g (0-255), int b (0-255), int a (0-255)
description {
"This is the premultiplied RGBA color with values fro 0 to 255 per"
"component"
}
}
func {
name: clear
description {
"Clears the color from the targe
Re: [E-devel] API docs
On Mon, 30 Oct 2017 16:47:08 + Andrew Williams said: done :) > Hi, > > I have now fixed the codelink plugin so it does not blow the limit for the > length of a regex compilation. Can you please try putting this > configuration back in again? > > $conf['code_extn'] = 'develop/api/ref'; > > Thanks, > Andy > > On Thu, 26 Oct 2017 at 02:57 Carsten Haitzler wrote: > > > On Thu, 26 Oct 2017 08:54:26 +0900 Carsten Haitzler > > said: > > > > > On Wed, 25 Oct 2017 17:09:06 + Andrew Williams > > > > > said: > > > > > > > Hi, > > > > > > > > Today I was looking at the autogenerated EO docs... They seem to be > > quite C > > > > specific - but they start with some great generic content. They also > > have > > > > some clever autolink reference generation specific to c. So I got to > > > > > > originally the plan was to ensure things not covered by eo like eina > > properly > > > got linked in just when putting the symbol anywhere in a doc anywhere on > > the > > > wiki. the doc generator could generate links for things is knew about (eo > > > methods/classes etc.). :) > > > > > > > thinking if we want to generate the API in multiple languages this > > script > > > > would be the best place to do it. And so therefore I have landed on > > > > mounting these docs in /develop/api so language specifics (such as > > ref/c) > > > > can be handled within that space. > > > > > > indeed it was meant for multiple languages too. starting with c and > > well... > > > we'll go from there. :) > > > > > > > As an outcome can raster or beber, or someone with local access to the > > wiki > > > > VM please change a line of the local.conf? > > > > > > > > $conf['code_extn'] = 'develop/api/ref'; > > > > > > done. :) > > > > undone .. setting that makes all the pages stop marking down -> html and > > you > > get raw markdown text... hm... > > > > > > Thanks :) > > > > Andrew > > > > -- > > > > http://andywilliams.me > > > > http://ajwillia.ms > > > > > > ------ > > > > Check out the vibrant tech community on one of the world's most > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > ___ > > > > enlightenment-devel mailing list > > > > enlightenment-devel@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > > -- > > > ----- Codito, ergo sum - "I code, therefore I am" -- > > > 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 > > > > > > > > > -- > > - Codito, ergo sum - "I code, therefore I am" -- > > 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 > > > -- > http://andywilliams.me > http://ajwillia.ms > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- 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] API docs
On Tue, 31 Oct 2017 08:26:20 + Andrew Williams said: > That's great thanks, it seems to be working well. > > Now that it's much more efficient I could change the default language to c > - so that any page that does not state otherwise will receive this markup. > Seems like a good thing to me - what do you think? well originally i didn't see an efficiency issue mostly because dokuwiki caches so first person to read an updated page may wait a little bit (what- a second? 2 seconds?) ... but after that its cached and flattened out. > Andy > > On Tue, 31 Oct 2017 at 07:36 Carsten Haitzler wrote: > > > On Mon, 30 Oct 2017 16:47:08 + Andrew Williams > > said: > > > > done :) > > > > > Hi, > > > > > > I have now fixed the codelink plugin so it does not blow the limit for > > the > > > length of a regex compilation. Can you please try putting this > > > configuration back in again? > > > > > > $conf['code_extn'] = 'develop/api/ref'; > > > > > > Thanks, > > > Andy > > > > > > On Thu, 26 Oct 2017 at 02:57 Carsten Haitzler > > wrote: > > > > > > > On Thu, 26 Oct 2017 08:54:26 +0900 Carsten Haitzler < > > ras...@rasterman.com> > > > > said: > > > > > > > > > On Wed, 25 Oct 2017 17:09:06 + Andrew Williams < > > a...@andywilliams.me > > > > > > > > > > said: > > > > > > > > > > > Hi, > > > > > > > > > > > > Today I was looking at the autogenerated EO docs... They seem to be > > > > quite C > > > > > > specific - but they start with some great generic content. They > > also > > > > have > > > > > > some clever autolink reference generation specific to c. So I got > > to > > > > > > > > > > originally the plan was to ensure things not covered by eo like eina > > > > properly > > > > > got linked in just when putting the symbol anywhere in a doc > > anywhere on > > > > the > > > > > wiki. the doc generator could generate links for things is knew > > about (eo > > > > > methods/classes etc.). :) > > > > > > > > > > > thinking if we want to generate the API in multiple languages this > > > > script > > > > > > would be the best place to do it. And so therefore I have landed on > > > > > > mounting these docs in /develop/api so language specifics (such as > > > > ref/c) > > > > > > can be handled within that space. > > > > > > > > > > indeed it was meant for multiple languages too. starting with c and > > > > well... > > > > > we'll go from there. :) > > > > > > > > > > > As an outcome can raster or beber, or someone with local access to > > the > > > > wiki > > > > > > VM please change a line of the local.conf? > > > > > > > > > > > > $conf['code_extn'] = 'develop/api/ref'; > > > > > > > > > > done. :) > > > > > > > > undone .. setting that makes all the pages stop marking down -> html > > and > > > > you > > > > get raw markdown text... hm... > > > > > > > > > > Thanks :) > > > > > > Andrew > > > > > > -- > > > > > > http://andywilliams.me > > > > > > http://ajwillia.ms > > > > > > > > > > > > -- > > > > > > Check out the vibrant tech community on one of the world's most > > > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > > ___ > > > > > > enlightenment-devel mailing list > > > > > > enlightenment-devel@lists.sourceforge.net > > > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > > > > > > > > > > -- > > > > > - Codito, ergo sum - "I code, therefore I am" > > -- > > > > > Carsten Haitzler - ras...@rasterman.com > > > > > > > > > > > > > > >
Re: [E-devel] Documentation into the Interfaces era :)
On Tue, 31 Oct 2017 08:18:37 + Andrew Williams said: > In the case of method/symbol documentation that is indeed correct and no > markup language is my first port of call for that. The first pass was done > with clang which is pretty good thus far - .eo is going to be much more > help once the interfaces become more commonly used. > > However what your email misses is all the other documentation that we are > hoping to reference - the helpful context documents (mainloop / alpha > blending) and examples or walkthroughs that would make a much better hand > holding experience. Like I said before this is intending to help folk get > started with EFL - the steep learning curve is due to much more than method > parameter order and bounds. ok. i was just thinking reference (struct/enum/func/method/property/class info) stuff. not things like tutorials and whatever. edi needing this tutorial land stuff seems more fringe. reference docs - absolutely. i can see this. like tooltips and completion info as you type telling you about what you are writing and the limits/sage and so on. i mean... at a stretch i can see edi showing these docs, but then doesn't it also have to handle inlined images (diagrams, screenshots and so on?). tables, and what not... right? > Thanks, > Andy > > On Tue, 31 Oct 2017 at 07:36 Carsten Haitzler wrote: > > > On Tue, 24 Oct 2017 13:39:14 + Andrew Williams > > said: > > > > > On Tue, 24 Oct 2017 at 13:09 Carsten Haitzler > > wrote: > > > > > > > On Mon, 23 Oct 2017 11:57:56 + Andrew Williams < > > a...@andywilliams.me> > > > > said: > > > > > > > > > Hi, > > > > > > > > > > I will try to provide as much insight as I can: > > > > > > > > > > As many of the community are aware I started the Edi project to help > > get > > > > > people into coding on EFL - the learning curve is very steep and the > > > > > tooling was basically commandline based. Documentation is a big part > > of > > > > the > > > > > solution and we've come a long way both with the wiki and with the > > .eo > > > > > format for defining functionality. However this is set up to deliver > > only > > > > > on our website which a) is online and b) is external to the IDE. > > > > > To make a more integrated experience I started to think about how the > > > > > documentation could be more portable - so that it could be rendered > > in > > > > Edi > > > > > or other documentation browser online or offline, in the workflow of > > > > > someone's coding. Dokuwiki is a challenge here as the only renderer > > is > > > > the > > > > > dokuwiki web ui so reading the files off the filesystem is not > > really a > > > > > possibility without coding up a new render implementation. > > > > > > > > i was actually thinking of the docs always being online... :) then > > changes > > > > and > > > > improvements are immediately accessible to all users/devs ... :) yes > > yes. > > > > hard > > > > to refer to docs while on a plane ... i know. :) > > > > > > > > > > In it's current form not only do you have to be online you have to have a > > > browser window open alongside your code. To be worried about immediate > > > propagation of improvements implies a lot more documentation activity > > than > > > we see - and once the API has a solid release would important changes to > > > them not be less common? > > > > > > > A few conversations later and I was chatting to Cedric about what we > > can > > > > do > > > > > to make the documentation cleaner and he mentioned that Samsung was > > also > > > > > interested in this - and that they may be willing to finance some > > > > technical > > > > > writers to help. So he managed to get some professionals signed up > > and > > > > now > > > > > have people raring to go with documentation - but they don't know > > > > dokuwiki > > > > > and honestly I don't think that spending all day editing text files > > in a > > > > > browser window is the best way to write reams of documentation. A > > markup > > > > > format with external editors would mean higher productivity and also > > > > > increased portability. > > > > > >
Re: [E-devel] Documentation into the Interfaces era :)
On Tue, 31 Oct 2017 10:01:43 + Andrew Williams said: > Hi > > Ideally yes - but then images are part of the spec anyway - and tables are > pretty standard these days. ok. so then it'd have to be a mixed bag of textblocks/entries + tables or boxes containing them with tables done outside of these widgets. more involved to create a display widget/layout at any rate. > Andy > > On Tue, 31 Oct 2017 at 08:37 Carsten Haitzler wrote: > > > On Tue, 31 Oct 2017 08:18:37 + Andrew Williams > > said: > > > > > In the case of method/symbol documentation that is indeed correct and no > > > markup language is my first port of call for that. The first pass was > > done > > > with clang which is pretty good thus far - .eo is going to be much more > > > help once the interfaces become more commonly used. > > > > > > However what your email misses is all the other documentation that we are > > > hoping to reference - the helpful context documents (mainloop / alpha > > > blending) and examples or walkthroughs that would make a much better hand > > > holding experience. Like I said before this is intending to help folk get > > > started with EFL - the steep learning curve is due to much more than > > method > > > parameter order and bounds. > > > > ok. i was just thinking reference (struct/enum/func/method/property/class > > info) > > stuff. not things like tutorials and whatever. edi needing this tutorial > > land > > stuff seems more fringe. reference docs - absolutely. i can see this. like > > tooltips and completion info as you type telling you about what you are > > writing > > and the limits/sage and so on. > > > > i mean... at a stretch i can see edi showing these docs, but then doesn't > > it > > also have to handle inlined images (diagrams, screenshots and so on?). > > tables, > > and what not... right? > > > > > Thanks, > > > Andy > > > > > > On Tue, 31 Oct 2017 at 07:36 Carsten Haitzler > > wrote: > > > > > > > On Tue, 24 Oct 2017 13:39:14 + Andrew Williams < > > a...@andywilliams.me> > > > > said: > > > > > > > > > On Tue, 24 Oct 2017 at 13:09 Carsten Haitzler > > > > wrote: > > > > > > > > > > > On Mon, 23 Oct 2017 11:57:56 + Andrew Williams < > > > > a...@andywilliams.me> > > > > > > said: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I will try to provide as much insight as I can: > > > > > > > > > > > > > > As many of the community are aware I started the Edi project to > > help > > > > get > > > > > > > people into coding on EFL - the learning curve is very steep and > > the > > > > > > > tooling was basically commandline based. Documentation is a big > > part > > > > of > > > > > > the > > > > > > > solution and we've come a long way both with the wiki and with > > the > > > > .eo > > > > > > > format for defining functionality. However this is set up to > > deliver > > > > only > > > > > > > on our website which a) is online and b) is external to the IDE. > > > > > > > To make a more integrated experience I started to think about > > how the > > > > > > > documentation could be more portable - so that it could be > > rendered > > > > in > > > > > > Edi > > > > > > > or other documentation browser online or offline, in the > > workflow of > > > > > > > someone's coding. Dokuwiki is a challenge here as the only > > renderer > > > > is > > > > > > the > > > > > > > dokuwiki web ui so reading the files off the filesystem is not > > > > really a > > > > > > > possibility without coding up a new render implementation. > > > > > > > > > > > > i was actually thinking of the docs always being online... :) then > > > > changes > > > > > > and > > > > > > improvements are immediately accessible to all users/devs ... :) > > yes > > > > yes. > > > > > > hard > > > > > > to refer to docs while on a plane ... i know. :) > > > > > > >
Re: [E-devel] API docs
On Tue, 31 Oct 2017 10:02:50 + Andrew Williams said: > Well, once you throw 4000 odd keywords, and match with or without () then > efficiency is an issue. > > Either way that was not the point - I figure we can turn code linking on > for all pages - any reason not to? > And it would default to c unless the header said otherwise... i wonder if it's have adverse side-effects on pages that are not talking about code. like accidentally link words that shouldn't be. i can't think of any cases where this might happen as our symbols all are xxx_yyy... so once you have a _ you're almost definitely talking about code... > Andy > > On Tue, 31 Oct 2017 at 08:37 Carsten Haitzler wrote: > > > On Tue, 31 Oct 2017 08:26:20 + Andrew Williams > > said: > > > > > That's great thanks, it seems to be working well. > > > > > > Now that it's much more efficient I could change the default language to > > c > > > - so that any page that does not state otherwise will receive this > > markup. > > > Seems like a good thing to me - what do you think? > > > > well originally i didn't see an efficiency issue mostly because dokuwiki > > caches > > so first person to read an updated page may wait a little bit (what- a > > second? > > 2 seconds?) ... but after that its cached and flattened out. > > > > > Andy > > > > > > On Tue, 31 Oct 2017 at 07:36 Carsten Haitzler > > wrote: > > > > > > > On Mon, 30 Oct 2017 16:47:08 + Andrew Williams < > > a...@andywilliams.me> > > > > said: > > > > > > > > done :) > > > > > > > > > Hi, > > > > > > > > > > I have now fixed the codelink plugin so it does not blow the limit > > for > > > > the > > > > > length of a regex compilation. Can you please try putting this > > > > > configuration back in again? > > > > > > > > > > $conf['code_extn'] = 'develop/api/ref'; > > > > > > > > > > Thanks, > > > > > Andy > > > > > > > > > > On Thu, 26 Oct 2017 at 02:57 Carsten Haitzler > > > > wrote: > > > > > > > > > > > On Thu, 26 Oct 2017 08:54:26 +0900 Carsten Haitzler < > > > > ras...@rasterman.com> > > > > > > said: > > > > > > > > > > > > > On Wed, 25 Oct 2017 17:09:06 + Andrew Williams < > > > > a...@andywilliams.me > > > > > > > > > > > > > > said: > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > Today I was looking at the autogenerated EO docs... They seem > > to be > > > > > > quite C > > > > > > > > specific - but they start with some great generic content. They > > > > also > > > > > > have > > > > > > > > some clever autolink reference generation specific to c. So I > > got > > > > to > > > > > > > > > > > > > > originally the plan was to ensure things not covered by eo like > > eina > > > > > > properly > > > > > > > got linked in just when putting the symbol anywhere in a doc > > > > anywhere on > > > > > > the > > > > > > > wiki. the doc generator could generate links for things is knew > > > > about (eo > > > > > > > methods/classes etc.). :) > > > > > > > > > > > > > > > thinking if we want to generate the API in multiple languages > > this > > > > > > script > > > > > > > > would be the best place to do it. And so therefore I have > > landed on > > > > > > > > mounting these docs in /develop/api so language specifics > > (such as > > > > > > ref/c) > > > > > > > > can be handled within that space. > > > > > > > > > > > > > > indeed it was meant for multiple languages too. starting with c > > and > > > > > > well... > > > > > > > we'll go from there. :) > > > > > > > > > > > > > > > As an outcome can raster or beber, or someone with local > > access to > > > > the > > > >
Re: [E-devel] Wiki playground
On Tue, 31 Oct 2017 16:15:21 + Andrew Williams said: done :) > Hi Raster (or web admin) > > Can you please set this config value in the dokuwiki conf/local.php? > > $conf['plugin']['gitbacked']['ignorePaths'] = 'pages/playground/'; > > I forgot that the config changes are not pushed and without it there is a > 500 error every time we write to playground (though it saves). > > Thanks, > Andy > > On Wed, 25 Oct 2017 at 14:23 Andrew Williams wrote: > > > Hi, > > > > I have updated the /playground part of our wiki to not write changes to > > git - this seems like the right thing to do. I have added it to gitignore > > and also the gitbacked plugin. > > As beber already noticed ( > > https://github.com/woolfg/dokuwiki-plugin-gitbacked/issues/43) upgrading > > the plugin has issues so to get a the ignore feature (added 3 years ago) I > > had to apply the patch from upstream. Once the upgrade succeeds it will > > simply overwrite these files so it's not blocking future updates at all. > > > > Let me know if you think that the playground should absolutely be tracked > > through our git repo. > > > > Andrew > > -- > > http://andywilliams.me > > http://ajwillia.ms > > > -- > http://andywilliams.me > http://ajwillia.ms > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- 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] E22 Schedule
On Tue, 31 Oct 2017 15:31:08 + Mike Blumenkrantz said: > After reviewing the currently reported issues I'm now planning to do the > final release on Thursday. If anyone is working on any last minute bug > fixes, please have them tested and committed by then. can you hold off on this until i look at the apps menu stuff? i juast am spotting it's using threads... and threads + efreet == bad. netstar just pointed this out to me (as throwing in locks into efreet seems to fix things for him). i suspect i need to review this and undo the threading if it's also doing efreet calls from there. -- - Codito, ergo sum - "I code, therefore I am" -- 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] E22 Schedule
On Wed, 01 Nov 2017 01:20:57 + Mike Blumenkrantz said: > There are no threads in the menu code that you are looking at, only > functions with names from a time when there was an attempt to make efreet > menu parsing asynchronous. yes. i looked into it and this is indeed the case. i grepped for thread and saw something and went "wait a sec...". it is indeed not using threads + efreet. but something else i think is. what - i'm not sure. but something... in e somewhere i think. > On Tue, Oct 31, 2017 at 8:56 PM Carsten Haitzler > wrote: > > > On Tue, 31 Oct 2017 15:31:08 + Mike Blumenkrantz > > said: > > > > > After reviewing the currently reported issues I'm now planning to do the > > > final release on Thursday. If anyone is working on any last minute bug > > > fixes, please have them tested and committed by then. > > > > can you hold off on this until i look at the apps menu stuff? i juast am > > spotting it's using threads... and threads + efreet == bad. netstar just > > pointed this out to me (as throwing in locks into efreet seems to fix > > things > > for him). > > > > i suspect i need to review this and undo the threading if it's also doing > > efreet calls from there. > > > > -- > > - Codito, ergo sum - "I code, therefore I am" -- > > Carsten Haitzler - ras...@rasterman.com > > > > -- - Codito, ergo sum - "I code, therefore I am" -- 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] E22 Schedule
On Wed, 01 Nov 2017 01:41:08 + Mike Blumenkrantz said: > Assuming you are looking at the Enlightenment internal menu code, that is. > If you are looking at the async efreet code, this has never successfully > been used and is not currently used anywhere that I am aware of. netstar did some patching of efreet and added some locks... and the problems seen with everything went away it seems. this is a red flag i think... so worth looking into. specifically the patch he pasted here: https://phab.enlightenment.org/T6084 that screams to me right now that someone, somewhere is calling efreet from threads. and it seems to only be affecting e... so e or some module shipped with e... i need to hunt a bit. it may has been related to menu too so i was wondering... and indeed at least: _scan_mime_func() in evry_plug_files.c which is a thread func calls efreet_mime_type_get() but this isn't related to menus though... :/ so i'm a bit baffled atm. i was going to add mainloop is call checks through efreet's api calls and barf if something is not called from mainloop. > On Tue, Oct 31, 2017 at 9:20 PM Mike Blumenkrantz < > michael.blumenkra...@gmail.com> wrote: > > > There are no threads in the menu code that you are looking at, only > > functions with names from a time when there was an attempt to make efreet > > menu parsing asynchronous. > > > > On Tue, Oct 31, 2017 at 8:56 PM Carsten Haitzler > > wrote: > > > >> On Tue, 31 Oct 2017 15:31:08 + Mike Blumenkrantz > >> said: > >> > >> > After reviewing the currently reported issues I'm now planning to do the > >> > final release on Thursday. If anyone is working on any last minute bug > >> > fixes, please have them tested and committed by then. > >> > >> can you hold off on this until i look at the apps menu stuff? i juast am > >> spotting it's using threads... and threads + efreet == bad. netstar just > >> pointed this out to me (as throwing in locks into efreet seems to fix > >> things > >> for him). > >> > >> i suspect i need to review this and undo the threading if it's also doing > >> efreet calls from there. > >> > >> -- > >> - Codito, ergo sum - "I code, therefore I am" -- > >> 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 > -- - Codito, ergo sum - "I code, therefore I am" -- 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] E22 Schedule
On Wed, 01 Nov 2017 01:41:08 + Mike Blumenkrantz said: > Assuming you are looking at the Enlightenment internal menu code, that is. > If you are looking at the async efreet code, this has never successfully > been used and is not currently used anywhere that I am aware of. it doesnt seem at least efreet menu is being used from any threads i can find... so go ahead with release. this isnt going to be found quickly. > On Tue, Oct 31, 2017 at 9:20 PM Mike Blumenkrantz < > michael.blumenkra...@gmail.com> wrote: > > > There are no threads in the menu code that you are looking at, only > > functions with names from a time when there was an attempt to make efreet > > menu parsing asynchronous. > > > > On Tue, Oct 31, 2017 at 8:56 PM Carsten Haitzler > > wrote: > > > >> On Tue, 31 Oct 2017 15:31:08 + Mike Blumenkrantz > >> said: > >> > >> > After reviewing the currently reported issues I'm now planning to do the > >> > final release on Thursday. If anyone is working on any last minute bug > >> > fixes, please have them tested and committed by then. > >> > >> can you hold off on this until i look at the apps menu stuff? i juast am > >> spotting it's using threads... and threads + efreet == bad. netstar just > >> pointed this out to me (as throwing in locks into efreet seems to fix > >> things > >> for him). > >> > >> i suspect i need to review this and undo the threading if it's also doing > >> efreet calls from there. > >> > >> -- > >> - Codito, ergo sum - "I code, therefore I am" -- > >> 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 > -- - Codito, ergo sum - "I code, therefore I am" -- 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] Documentation into the Interfaces era :)
On Wed, 01 Nov 2017 18:27:51 + Andrew Williams said: > Hi, > > Whatever rendering technologies we use within Edi is probably out of scope > for this thread which was (in part) about using a more portable > documentation format to allow folk to access the docs outwith the E website > context. > Markdown is working well for the documentation team as they can use their > own editors before adding to the wiki for any final tweaks / links etc. > I don't know about others but I think we're about out of reasons not to > support this going forward. well let's see. i still dislike us now having 2 markdown formats on our main site. > Thanks, > Andy > > On Wed, 1 Nov 2017 at 00:53 Carsten Haitzler wrote: > > > On Tue, 31 Oct 2017 10:01:43 + Andrew Williams > > said: > > > > > Hi > > > > > > Ideally yes - but then images are part of the spec anyway - and tables > > are > > > pretty standard these days. > > > > ok. so then it'd have to be a mixed bag of textblocks/entries + tables or > > boxes > > containing them with tables done outside of these widgets. more involved to > > create a display widget/layout at any rate. > > > > > Andy > > > > > > On Tue, 31 Oct 2017 at 08:37 Carsten Haitzler > > wrote: > > > > > > > On Tue, 31 Oct 2017 08:18:37 + Andrew Williams < > > a...@andywilliams.me> > > > > said: > > > > > > > > > In the case of method/symbol documentation that is indeed correct > > and no > > > > > markup language is my first port of call for that. The first pass was > > > > done > > > > > with clang which is pretty good thus far - .eo is going to be much > > more > > > > > help once the interfaces become more commonly used. > > > > > > > > > > However what your email misses is all the other documentation that > > we are > > > > > hoping to reference - the helpful context documents (mainloop / alpha > > > > > blending) and examples or walkthroughs that would make a much better > > hand > > > > > holding experience. Like I said before this is intending to help > > folk get > > > > > started with EFL - the steep learning curve is due to much more than > > > > method > > > > > parameter order and bounds. > > > > > > > > ok. i was just thinking reference > > (struct/enum/func/method/property/class > > > > info) > > > > stuff. not things like tutorials and whatever. edi needing this > > tutorial > > > > land > > > > stuff seems more fringe. reference docs - absolutely. i can see this. > > like > > > > tooltips and completion info as you type telling you about what you are > > > > writing > > > > and the limits/sage and so on. > > > > > > > > i mean... at a stretch i can see edi showing these docs, but then > > doesn't > > > > it > > > > also have to handle inlined images (diagrams, screenshots and so on?). > > > > tables, > > > > and what not... right? > > > > > > > > > Thanks, > > > > > Andy > > > > > > > > > > On Tue, 31 Oct 2017 at 07:36 Carsten Haitzler > > > > wrote: > > > > > > > > > > > On Tue, 24 Oct 2017 13:39:14 + Andrew Williams < > > > > a...@andywilliams.me> > > > > > > said: > > > > > > > > > > > > > On Tue, 24 Oct 2017 at 13:09 Carsten Haitzler < > > ras...@rasterman.com> > > > > > > wrote: > > > > > > > > > > > > > > > On Mon, 23 Oct 2017 11:57:56 + Andrew Williams < > > > > > > a...@andywilliams.me> > > > > > > > > said: > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I will try to provide as much insight as I can: > > > > > > > > > > > > > > > > > > As many of the community are aware I started the Edi project > > to > > > > help > > > > > > get > > > > > > > > > people into coding on EFL - the learning curve is very steep > > and > > > > the > > > > > > > > > tooling was basically commandline base
Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: shot - add a padded screenshot so it can also grab shadows/surrounds
On Fri, 03 Nov 2017 11:28:28 + Mike Blumenkrantz
said:
> I see what you are going for here based on the theme that you have been
> working on, and I think it would be a nice improvement overall to have this
actually it applies to default too.. :)
> sort of feature, but I think that this is not the best way to go about
> it--specifically adding it to the window menu since there are now two
> screenshot items, though the general implementation also seems to be
> something that would only be used by you since it either adds a large
> amount of padding by default or requires the user to trial+error in order
> to achieve the desired results.
i just kind of thought i chose a pretty good default that would "do the job 99%
of the time anyway"... if that's what you wanted. it does make for much nicer
screenshots of specific windows. :)
the problem here is we don't actually know the dimensions of the shadow. it's
done outside the object bounds, thus just taking some value is about as good as
it gets at this point. well in x11. in wayland we do. but if we calculated it
given current shadows the top padding would be less, bottom more etc. so you'd
want to take the max anyway.
> I think the better solution for reliably capturing shadows on windows would
> be to do something like add a feature for snapshot objects where setting
> the clip to an object under it will restrict it to only being a snapshot
> from image data resulting from that object. Then all window-based
> screenshots could automatically be made to capture shadows and do it
> accurately.
i did indeed try proxies... they ended up blank with no content... (creates an
image set src to ec->frame etc. etc.) and that still has the above "shadow is
done outside of object bounds" thing where you can't grab it via a proxy this
way anyway... :(
> Alternatively, dynamic cropping from e.g., emprint or ephoto could be added
> to the base screenshot gui which would be a useful feature for many cases.
that was on a list of things to "add later" as it would take more work. also
if it were just simply "draw a rect to crop" it's lead to inconsistent padding
around windows. to do it well it'd be a bit like the screen select but you can
click on windows, then click and drag handles outside of the window, maybe with
a "add std padding" button with some field with the padding amount to add
around the bounds etc. - definitely more work by a good chunk.
what i have done is a very quick and simple solution to having window shots
actually look "nice" with their surrounding decorations and shadow ... if you
want. i kept the non-padded entry because sometimes you don't want other windows
around your to leak into the shot... not the nicest of solutions, but it's a
pretty quick and simple one for now.
> On Fri, Nov 3, 2017 at 3:18 AM Carsten Haitzler
> wrote:
>
> > raster pushed a commit to branch master.
> >
> >
> > http://git.enlightenment.org/core/enlightenment.git/commit/?id=2be56cd8da7ae656f37f3894c1e5a6f66ff9f4b2
> >
> > commit 2be56cd8da7ae656f37f3894c1e5a6f66ff9f4b2
> > Author: Carsten Haitzler (Rasterman)
> > Date: Fri Nov 3 16:16:45 2017 +0900
> >
> > shot - add a padded screenshot so it can also grab shadows/surrounds
> >
> > nice to get a shot that also has the shadows etc. add as menu and
> > param options
> >
> > @feature
> > ---
> > src/modules/shot/e_mod_main.c | 89
> > +++
> > 1 file changed, 65 insertions(+), 24 deletions(-)
> >
> > diff --git a/src/modules/shot/e_mod_main.c b/src/modules/shot/e_mod_main.c
> > index 9929dd6e7..fd0599a25 100644
> > --- a/src/modules/shot/e_mod_main.c
> > +++ b/src/modules/shot/e_mod_main.c
> > @@ -605,6 +605,7 @@ _save_dialog_show(E_Zone *zone, E_Client *ec, const
> > char *params, void *dst, int
> > Evas_Modifier_Mask mask;
> > E_Radio_Group *rg;
> > int w, h;
> > + char smode[128], squal[128], sscreen[128];
> >
> > win = elm_win_add(NULL, NULL, ELM_WIN_BASIC);
> >
> > @@ -768,27 +769,23 @@ _save_dialog_show(E_Zone *zone, E_Client *ec, const
> > char *params, void *dst, int
> > evas_object_size_hint_min_set(win, w, h);
> > evas_object_size_hint_max_set(win, 9, 9);
> >
> > - if (params)
> > + if ((params) &&
> > + (sscanf(params, "%100s %100s %100s", smode, squal, sscreen) == 3))
> > {
> > -char smode[128], squal[128], sscreen[128];
> > -
> > -if (sscanf(params, "%100s %100s %100s", smode, squal, sscreen) ==
> > 3)
> >
Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: shot - add a padded screenshot so it can also grab shadows/surrounds
On Fri, 03 Nov 2017 14:10:28 + Mike Blumenkrantz said: > On Fri, Nov 3, 2017 at 9:50 AM Carsten Haitzler > wrote: > > > On Fri, 03 Nov 2017 11:28:28 + Mike Blumenkrantz > > said: > > > > > I see what you are going for here based on the theme that you have been > > > working on, and I think it would be a nice improvement overall to have > > this > > > > actually it applies to default too.. :) > > > > Nobody cares about the shadows in a theme which has been the default for > over 5 years :) :) :) :) :) > > > > > > > sort of feature, but I think that this is not the best way to go about > > > it--specifically adding it to the window menu since there are now two > > > screenshot items, though the general implementation also seems to be > > > something that would only be used by you since it either adds a large > > > amount of padding by default or requires the user to trial+error in order > > > to achieve the desired results. > > > > i just kind of thought i chose a pretty good default that would "do the > > job 99% > > of the time anyway"... if that's what you wanted. it does make for much > > nicer > > screenshots of specific windows. :) > > > > the problem here is we don't actually know the dimensions of the shadow. > > it's > > done outside the object bounds, thus just taking some value is about as > > good as > > it gets at this point. well in x11. in wayland we do. but if we calculated > > it > > given current shadows the top padding would be less, bottom more etc. so > > you'd > > want to take the max anyway. > > > > Using edje_object_parts_extends_calc() would yield correct dimensions for > server-side shadows, and there are themes which have used this to have > resize trigger based on pointer interaction with the shadow region in x11. i didn't know that had been added. > > > I think the better solution for reliably capturing shadows on windows > > would > > > be to do something like add a feature for snapshot objects where setting > > > the clip to an object under it will restrict it to only being a snapshot > > > from image data resulting from that object. Then all window-based > > > screenshots could automatically be made to capture shadows and do it > > > accurately. > > > > i did indeed try proxies... they ended up blank with no content... > > (creates an > > image set src to ec->frame etc. etc.) and that still has the above "shadow > > is > > done outside of object bounds" thing where you can't grab it via a proxy > > this > > way anyway... :( > > Snapshot object, not proxy. I've created a task for it. > https://phab.enlightenment.org/T6312 sure. but proxies would be the only way to capture a specific object and not everything below it too at this point. :) > > > Alternatively, dynamic cropping from e.g., emprint or ephoto could be > > added > > > to the base screenshot gui which would be a useful feature for many > > cases. > > > > that was on a list of things to "add later" as it would take more work. > > also > > if it were just simply "draw a rect to crop" it's lead to inconsistent > > padding > > around windows. to do it well it'd be a bit like the screen select but you > > can > > click on windows, then click and drag handles outside of the window, maybe > > with > > a "add std padding" button with some field with the padding amount to add > > around the bounds etc. - definitely more work by a good chunk. > > > > what i have done is a very quick and simple solution to having window shots > > actually look "nice" with their surrounding decorations and shadow ... if > > you > > want. i kept the non-padded entry because sometimes you don't want other > > windows > > around your to leak into the shot... not the nicest of solutions, but it's > > a > > pretty quick and simple one for now. > > > > I understand why you did it as well as why you did it the way you did, but > I disagree with the latter. Having more parameters to an action that only > extreme power users will ever notice is whatever, but adding extra menu > items which duplicate the functionality of existing menu items is not > ideal. The toplevel menu should contain exactly one item for taking > screenshots of windows, not one for taking screenshots and a second for > taking slightly larger screenshots. wile it doesnt look brilliant my choices are
Re: [E-devel] Autotools removal
On Fri, 03 Nov 2017 18:07:10 + Mike Blumenkrantz said: > The E22 release is out now, so it's time to return to this issue. Currently > we have two build systems, and maintaining/updating both of them is not > feasible. At present, there is already significant divergence and various agreed. except for a very short term transition it's just not sustainable. i think it's already gone past the "short term" already. > features are not present in the autotools build (and never will be). The > decision is not whether to remove autotools or when to remove autotools, > it's what do we do about old distros. IMHO remove autotools, and deal with the issues as they come up with meson. > Based on previous discussions, it seems that there are still some users > whose distros do not yet ship a modern enough version of meson. The best > option, which is the option other projects which switch to meson have been > using, is to simply ship a tarball of a newer meson release along with our > code. The other option is to provide a link in the README. I don't have any > other ideas. i think that the above should be enough. in time the problem will go away. > I'll be removing autotools sometime next week, let's try to get some > discussion going about the best action to take going forward with this. in rage i still have autogen.sh ... but is does: rm -rf build meson $@ . build mesonconf build perhaps keep autogen.sh like rage BUT it has some shell at the start which checks if meson exists on the target system then checks version, and if it's not new enough it wget's/curl fetches a new enough meson tarball, installs it locally in the tree in a tmp meson dir and sets path so that meson is found? long term we can remove that chunk of shell. people can also read the README and install a newer meson by hand if they want... > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- 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] OS X build error
On Sat, 04 Nov 2017 11:21:09 + Andrew Williams said:
> Can anyone help with this one please?
>
>
> Thanks,
>
> Andy
>
>
> CC
> modules/elementary/clock_input_ctxpopup/modules_elementary_clock_input_ctxpopup_module_la-clock_input_ctxpopup.lo
>
> CCLD modules/elementary/clock_input_ctxpopup/module.la
>
> Undefined symbols for architecture x86_64:
>
> "__ELM_CTXPOPUP_EVENT_DISMISSED", referenced from:
>
> __field_clicked_cb in
> modules_elementary_clock_input_ctxpopup_module_la-clock_input_ctxpopup.o
that sounds totally bizarre because the function is _field_clicked_cb:
static void
_field_clicked_cb(void *data, const Efl_Event *event)
{
> ld: symbol(s) not found for architecture x86_64
>
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
> make[4]: *** [modules/elementary/clock_input_ctxpopup/module.la] Error 1
>
> make[3]: *** [all-recursive] Error 1
>
> make[2]: *** [all] Error 2
>
> make[1]: *** [all-recursive] Error 1
>
> make: *** [all] Error 2
> --
> http://andywilliams.me
> http://ajwillia.ms
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
- Codito, ergo sum - "I code, therefore I am" --
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] efler issues on mac
.1.dylib 0x10a9d9d01 0x10a9b8000 > >> > /opt/efler/lib/libeina.1.dylib 0x10a9f142c 0x10a9b8000 > >> > /opt/efler/lib/libeldbus.1.dylib 0x10b189c7e 0x10b17f000 > >> > /opt/efler/lib/ecore/system/upower/v-1.20/module.so 0x10ae6a9fb > >> > 0x10ae69000 > >> > /opt/efler/lib/ecore/system/upower/v-1.20/module.so 0x10ae6a9b3 > >> > 0x10ae69000 > >> > /opt/efler/lib/libeina.1.dylib 0x10a9e69d9 0x10a9b8000 > >> > /opt/efler/lib/libeina.1.dylib 0x10a9e7686 0x10a9b8000 > >> > /opt/efler/lib/libecore.1.dylib 0x10ab65f80 0x10ab64000 > >> > /opt/efler/lib/libecore.1.dylib 0x10ab65995 0x10ab64000 > >> > /opt/efler/lib/efreet/v-1.20/efreet_desktop_cache_create 0x10a94b8a1 > >> > 0x10a94a000 > >> > /usr/lib/system/libdyld.dylib 0x7fff7fb53115 0x7fff7fb52000 > >> > EOF > >> /opt/efler/lib/libeina.1.dylib > >> | ??/eina_log.c : 2055 @ eina_log_print_cb_stderr() > >> /opt/efler/lib/libeina.1.dylib > >> | ??/eina_log.c : 1456 @ eina_log_print_unlocked() > >> /opt/efler/lib/libeina.1.dylib > >> | ??/eina_log.c : 2260 @ eina_log_print() > >> /opt/efler/lib/libeina.1.dylib > >> | ??/eina_safety_checks.c : 85 @ _eina_safety_error() > >> /opt/efler/lib/libeldbus.1.dylib > >> | ??/eldbus_core.c: 1399 @ > >> eldbus_name_owner_changed_callback_del() > >> /opt/efler/lib/ecore/system/upower/v-1.20/module.so > >> | ??/ecore_system_upower.c: 473 @ _ecore_system_upower_shutdown() > >> /opt/efler/lib/ecore/system/upower/v-1.20/module.so > >> | ??/ecore_system_upower.c: 460 @ _ecore_system_upower_init() > >> /opt/efler/lib/libeina.1.dylib > >> | ??/eina_module.c: 339 @ eina_module_load() > >> /opt/efler/lib/libeina.1.dylib > >> | ??/eina_module.c: 572 @ eina_module_list_load() > >> /opt/efler/lib/libecore.1.dylib > >> | ??/ecore.c : 188 @ ecore_system_modules_load() > >> /opt/efler/lib/libecore.1.dylib > >> | ??/ecore.c : 323 @ ecore_init() > >> > >> /opt/efler/lib/efreet/v-1.20/efreet_desktop_cache_create| ??/?? > >> : -1 @ 0x18a1() > >>/usr/lib/system/libdyld.dylib > >> | ??/?? : -1 @ 0x1115() > >> > >> > >> If you would like to provide me with guidance on how to fix this > >> please > >> do as I would like to start contributing to the project especially > >> with > >> mac related things. > >> > >> > >> -- > >> 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 > -- - Codito, ergo sum - "I code, therefore I am" -- 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] [EGIT] [core/enlightenment] master 02/02: smart suspend - honor suspend on ac or not flag as it should
On Thu, 19 Oct 2017 11:37:48 + Mike Blumenkrantz said: aaah that. done. https://phab.enlightenment.org/T6320 > Thanks for this--I can refer users who are still using older versions to > the ticket you created--but I was hoping you would create a ticket for the > remaining efl todo items that you cited in the commit log. > > On Wed, Oct 18, 2017 at 9:25 PM Carsten Haitzler > wrote: > > > On Wed, 18 Oct 2017 13:20:34 + Mike Blumenkrantz > > said: > > > > done > > > > > Can you create a task for this on phab? > > > > > > On Wed, Oct 18, 2017 at 12:37 AM Carsten Haitzler > > > wrote: > > > > > > > raster pushed a commit to branch master. > > > > > > > > > > > > > > http://git.enlightenment.org/core/enlightenment.git/commit/?id=0fada409175333e4ebeee30cab2ccd4ff457445f > > > > > > > > commit 0fada409175333e4ebeee30cab2ccd4ff457445f > > > > Author: Carsten Haitzler (Rasterman) > > > > Date: Wed Oct 18 13:33:47 2017 +0900 > > > > > > > > smart suspend - honor suspend on ac or not flag as it should > > > > > > > > so if you closed the lid ANd didn't have external screens ANd had > > ac > > > > plugged in ... e would suspend even if youdidn't have "suspend on > > ac" > > > > checked in blanking dialog. respect this and handle it properly. > > > > > > > > @fix > > > > > > > > side note... i've notced acpid no longer reporting lid events on > > one > > > > of my systems. this is very sucky. you now have to open > > > > /dev/input/event2 (this may vary from device to device) to get lid > > > > events... it's an input device. this means elput needs to start > > doing > > > > this as we cant get power button or lid events anymore and we > > may > > > > have to do this for x11 too. > > > > --- > > > > src/bin/e_acpi.c | 1 + > > > > src/bin/e_actions.c | 23 +-- > > > > src/bin/e_powersave.c | 35 +++ > > > > src/bin/e_powersave.h | 3 +++ > > > > src/bin/e_sys.c | 5 + > > > > 5 files changed, 65 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > > -- > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > ___ > > > enlightenment-devel mailing list > > > enlightenment-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > -- > > - Codito, ergo sum - "I code, therefore I am" -- > > 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 > -- - Codito, ergo sum - "I code, therefore I am" -- 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] efl_refcount_get
On Mon, 06 Nov 2017 09:46:41 + Andrew Williams said: i'd have to disagree on it being misleading... :/ > Hi, > > Whilst writing the docs we have realised that efl_ref_get is a slightly > misleading method name as it returns the reference count. Whilst we are > breaking APIs for our first interfaces release would people mind me > changing efl_ref_get to efl_refcount_get (as per this eo patch, and all the > efl ramifications). > > I'd prefer not to leave the old method in place but could do so if you > think there is a big problem making this breaking change? > > Thanks :) > Andy > > > -- > http://andywilliams.me > http://ajwillia.ms -- - Codito, ergo sum - "I code, therefore I am" -- 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] OS X build error
On Tue, 07 Nov 2017 09:08:04 + Andrew Williams said:
> Hi,
>
> It got us much closer - it now fails with the following:
>
> CXXLDlib/evas/libevas.la
>
> Undefined symbols for architecture x86_64:
>
> "_LKI", referenced from:
>
> __evas_common_font_int_cache_init in
> lib_evas_libevas_la-evas_font_load.o
>
> _evas_common_font_memory_load in lib_evas_libevas_la-evas_font_load.o
>
> _evas_common_font_load in lib_evas_libevas_la-evas_font_load.o
>
> _evas_common_font_init in lib_evas_libevas_la-evas_font_main.o
>
> ld: symbol(s) not found for architecture x86_64
>
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
> make[4]: *** [lib/evas/libevas.la] Error 1
that is very odd. they are specced with
src/lib/evas/common/evas_font.h:EAPI RGBA_Font
*evas_common_font_memory_load (const char *source, const char *name,
int size, const void *data, int data_size, Font_Rend_Flags wanted_rend,
Efl_Text_Font_Bitmap_Scalable bitmap_scalable);
for example. EAPI ... should still be defined to make these visible functions.
could EAPI be mis-defined there causing this?
>
> Thanks,
>
> Andy
>
> On Tue, 7 Nov 2017 at 01:48 Jean-Philippe André wrote:
>
> > EAPI is redefined to (nothing/dllimport) after Elementary.h, so I had
> > introduced elm_module_helper.h to re-define EAPI for those modules.
> > I think that keeping EAPI defined after Elementary.h caused problems on
> > Windows where application's EAPI were marked as dllimport instead of
> > dllexport (or something like that, I can't remember very well).
> >
> > Anyway I pushed a patch, let us know if this fixes the build for OSX.
> > Thanks!
> >
> >
> > 2017-11-07 5:37 GMT+09:00 Jean Guyomarc'h :
> >
> > > Hi,
> > >
> > > Eo events are generated as:
> > > EWAPI const Efl_Event_Description __BLAH =
> > EFL_EVENT_DESCRIPTION("blah");
> > >
> > > this yields private symbols that are not exported outside of
> > libelementary.
> > > Hence link failure with elm modules...
> > > But I don't understand why.
> > >
> > >
> > > Jean
> > >
> > > On Sat, Nov 4, 2017 at 5:39 PM, Jean Guyomarc'h <
> > jean.guyoma...@gmail.com>
> > > wrote:
> > >
> > > > hi,
> > > >
> > > > i'm not at home, and cannot really help. if there is a ticket open, i
> > may
> > > > have a look on monday. is that on git master ?
> > > >
> > > > thanks
> > > > Jean
> > > >
> > > >
> > > > On Nov 4, 2017 15:03, "Carsten Haitzler" wrote:
> > > >
> > > > On Sat, 04 Nov 2017 11:21:09 + Andrew Williams <
> > a...@andywilliams.me
> > > >
> > > > said:
> > > >
> > > > > Can anyone help with this one please?
> > > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Andy
> > > > >
> > > > >
> > > > > CC
> > > > > modules/elementary/clock_input_ctxpopup/modules_elementary_
> > > > clock_input_ctxpopup_module_la-clock_input_ctxpopup.lo
> > > > >
> > > > > CCLD modules/elementary/clock_input_ctxpopup/module.la
> > > > >
> > > > > Undefined symbols for architecture x86_64:
> > > > >
> > > > > "__ELM_CTXPOPUP_EVENT_DISMISSED", referenced from:
> > > > >
> > > > > __field_clicked_cb in
> > > > > modules_elementary_clock_input_ctxpopup_module_la-
> > > clock_input_ctxpopup.o
> > > >
> > > > that sounds totally bizarre because the function is _field_clicked_cb:
> > > >
> > > > static void
> > > > _field_clicked_cb(void *data, const Efl_Event *event)
> > > > {
> > > >
> > > > > ld: symbol(s) not found for architecture x86_64
> > > > >
> > > > > clang: error: linker command failed with exit code 1 (use -v to see
> > > > > invocation)
> > > > >
> > > > > make[4]: *** [modules/elementary/clock_input_ctxpopup/module.la]
> > > Error 1
> > > > >
> > > > > make[3]: *** [all-recursive] Error 1
> > > > >
> > > > > make[2]: *** [all] Error 2
> > > > >
> > > > > m
Re: [E-devel] efl_refcount_get
On Mon, 06 Nov 2017 09:53:32 + Andrew Williams said: > Can you please explain why? This is a method that returns a count of > references but has no mention of count in the name. Well your original email gave no details as to why it's misleading. I disagree because i see something like: Eo *efl_ref(Eo *obj); int efl_ref_get(Eo *obj); void efl_unref(Eo *obj); ... i.e. the context of the api, and to me it screams of "ref is reference or references" and since there is something to ref and unref already ref_get returning an int obviously is returning a reference count (to me). since i'm familiar with reference counting techniques in general (nothing to do with the code implementation or api here), to me it's obvious that this returns the reference count (an integer) and it's short form for that. if i saw this api in glib or gtk or libjpeg or libpng or zlib or any other library i'd think the same with zero documentation and just api signatures like the above. i've learned api's by just reading .h files (like xlib) and seeing this and taking a guess as to what it means. an int generally to me indicates it's returning a number as opposed to something opaque in higher level libs like efl/gtk etc.. it has meaning. libc calls return ints and are different as they tend to mean an error or success, but look at glib or gtk or others and they dont do this and efl doesn't do the libc thing either as a whole. so given the context as a whole and as a sub-part of the api like above... i disagree that its misleading. to me its pretty obvious. maybe because i've spent a lot of time with various api's and so on i tend to fill in the blanks quickly seeing this kind of information. i don't know. but if you think it's misleading can you give more information? why is it misleading? what is it leading you to think it is and why is that? what is the difference in view point or experience and how conclusions are being attained? > We have ref_add and wref_add that are talking about actual references but > ref_get returns a count? > This is misleading. > > Andy > > On Mon, 6 Nov 2017 at 09:49 Carsten Haitzler wrote: > > > On Mon, 06 Nov 2017 09:46:41 + Andrew Williams > > said: > > > > i'd have to disagree on it being misleading... :/ > > > > > Hi, > > > > > > Whilst writing the docs we have realised that efl_ref_get is a slightly > > > misleading method name as it returns the reference count. Whilst we are > > > breaking APIs for our first interfaces release would people mind me > > > changing efl_ref_get to efl_refcount_get (as per this eo patch, and all > > the > > > efl ramifications). > > > > > > I'd prefer not to leave the old method in place but could do so if you > > > think there is a big problem making this breaking change? > > > > > > Thanks :) > > > Andy > > > > > > > > > -- > > > http://andywilliams.me > > > http://ajwillia.ms > > > > > > -- > > - Codito, ergo sum - "I code, therefore I am" -- > > Carsten Haitzler - ras...@rasterman.com > > > > -- > http://andywilliams.me > http://ajwillia.ms > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- 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] Website Table of Contents
On Mon, 06 Nov 2017 18:47:45 + Andrew Williams said: > Hi, > > With some of the examples in our new documentation there is a lot of > content and there was a request to generate a table of contents. > This feature has been turned off on our wiki and I wondered how people > would feel about us turning this back on. With the current styling it looks > like this screenshot: > https://www.enlightenment.org/ss/e-5a00adba813593.05237914.jpg Hmmm... My take is that I don't like it. Dokuwiki by default had a TOC and I actually turned it off it. It took up too much horizontal space in most places. it comes off badly when your browser windows are not maximized or on portrait screens (tablets, phones)... so that is why I did this. Making pages too wide (expand so they fill a maximize screen) generally makes line reading harder (there is a reason newspapers etc. use narrow columns), thus why limiting the width of content tended to make for nicer presentation. And dokuwiki was all about presenting the front of "enlightenment.org" nicely to the world, so that's why I limited the width. I wasn't going to spend unlimited time on doing the www layout, design and content so I had to make compromises of work vs result. If i could get css/whatever to columnize layout somehow nicely across multiple screen sizes/types in dokuwiki it may have been a better solution. But time and effort. Anyway - that's why i did it and what i think about the TOC thing. > Frustratingly it's a global config, though it can be turned off on a > per-page basis. We can tweak what is included (again globally) but I > thought I would get a feeling for whether anyone felt strongly about this That was part of the issue and why I just turned it off as I thought it was more pain than good (as above) for much of the site. I generally think if your page is so long you need a TOC... perhaps you should split it up into multiple pages? :) My thoughts on it anyway... > Thanks, > Andy > -- > http://andywilliams.me > http://ajwillia.ms > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- 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] efl_refcount_get
On Tue, 07 Nov 2017 14:18:04 + Andrew Williams said: > Hi, > > Indeed on later reading I see it was lacking in detail so I followed up > later. > > It’s unclear if, following rasters last email, he is still in agreement > with the _count() change but it seems like an improvement so I intend to go > forward with it as discussed. i'm fine with it. i was just explaining why i disagreed in detail about it being misleading. :) > Thanks, > Andy > On Tue, 7 Nov 2017 at 13:57, Mike Blumenkrantz < > michael.blumenkra...@gmail.com> wrote: > > > In this case I would agree with raster; the original mail could have > > provided a little more detail because it is non-obvious to the reader why > > this could be misleading for users. > > > > efl_ref_count() is in line with the rest of our naming (e.g., > > eina_array_count(), eina_list_count(), eina_hash_population(), etc) and > > seems like a clear improvement. Nice work. > > > > On Tue, Nov 7, 2017 at 7:41 AM Carsten Haitzler > > wrote: > > > > > On Mon, 06 Nov 2017 09:53:32 + Andrew Williams > > > > > said: > > > > > > > Can you please explain why? This is a method that returns a count of > > > > references but has no mention of count in the name. > > > > > > Well your original email gave no details as to why it's misleading. I > > > disagree > > > because i see something like: > > > > > > Eo *efl_ref(Eo *obj); > > > int efl_ref_get(Eo *obj); > > > void efl_unref(Eo *obj); > > > ... > > > > > > i.e. the context of the api, and to me it screams of "ref is reference or > > > references" and since there is something to ref and unref already ref_get > > > returning an int obviously is returning a reference count (to me). since > > > i'm > > > familiar with reference counting techniques in general (nothing to do > > with > > > the > > > code implementation or api here), to me it's obvious that this returns > > the > > > reference count (an integer) and it's short form for that. > > > > > > if i saw this api in glib or gtk or libjpeg or libpng or zlib or any > > other > > > library i'd think the same with zero documentation and just api > > signatures > > > like > > > the above. > > > > > > i've learned api's by just reading .h files (like xlib) and seeing this > > and > > > taking a guess as to what it means. an int generally to me indicates it's > > > returning a number as opposed to something opaque in higher level libs > > like > > > efl/gtk etc.. it has meaning. libc calls return ints and are different as > > > they > > > tend to mean an error or success, but look at glib or gtk or others and > > > they > > > dont do this and efl doesn't do the libc thing either as a whole. > > > > > > so given the context as a whole and as a sub-part of the api like > > above... > > > i > > > disagree that its misleading. to me its pretty obvious. maybe because > > i've > > > spent a lot of time with various api's and so on i tend to fill in the > > > blanks > > > quickly seeing this kind of information. i don't know. > > > > > > but if you think it's misleading can you give more information? why is it > > > misleading? what is it leading you to think it is and why is that? what > > is > > > the > > > difference in view point or experience and how conclusions are being > > > attained? > > > > > > > We have ref_add and wref_add that are talking about actual references > > but > > > > ref_get returns a count? > > > > This is misleading. > > > > > > > > Andy > > > > > > > > On Mon, 6 Nov 2017 at 09:49 Carsten Haitzler > > > wrote: > > > > > > > > > On Mon, 06 Nov 2017 09:46:41 + Andrew Williams < > > > a...@andywilliams.me> > > > > > said: > > > > > > > > > > i'd have to disagree on it being misleading... :/ > > > > > > > > > > > Hi, > > > > > > > > > > > > Whilst writing the docs we have realised that efl_ref_get is a > > > slightly > > > > > > misleading method name as it returns the reference count. Whilst we > > > are > > > >
Re: [E-devel] Website Table of Contents
On Tue, 07 Nov 2017 15:59:24 + Andrew Williams said: > Hi, > > The amount of space it takes up is a stylistic issue - our template > explicitly reserves 1/4 of the screen for a ToC which is clearly not a > requirement. that was my major thing about it. stylistic. :) also the original css for it was a bit blergh and i didn't feel like fixing it up to be nicer so removing was less work. that's why i didnt do the TOC though. if you're going to do one... do it well. :) > Additionally of concern is that many of our pages (specifically the program > guide) have (manually entered) contents areas that are within the page > content. > https://www.enlightenment.org/develop/legacy/program_guide/eina/arrays That's kind of odd... I'd just remove it IMHO... :) > As part of this documentation effort we are seeing navigation as an area in > which we are significantly lacking so I think we can spend some time fixing > it. > I am a little unsure as to whether the main objection here is that we see > ToC as a bad thing or if we just did not find a way to include it neatly in > our layout. a little of the first but mostly the second. if you need a TOC because the page is so big ... i kind of think it should be split up... :) > If it were possible to make it well presented would people be generally in > favour of moving the ToCs into a standard (sidebar?) area so, where pages > need it, we can have the contents presented in a standard form (whilst > being auto generated)? see the first above :) > Thanks, > Andrew > > On Tue, 7 Nov 2017 at 12:51 Carsten Haitzler wrote: > > > On Mon, 06 Nov 2017 18:47:45 + Andrew Williams > > said: > > > > > Hi, > > > > > > With some of the examples in our new documentation there is a lot of > > > content and there was a request to generate a table of contents. > > > This feature has been turned off on our wiki and I wondered how people > > > would feel about us turning this back on. With the current styling it > > looks > > > like this screenshot: > > > https://www.enlightenment.org/ss/e-5a00adba813593.05237914.jpg > > > > Hmmm... My take is that I don't like it. Dokuwiki by default had a TOC and > > I > > actually turned it off it. It took up too much horizontal space in most > > places. > > it comes off badly when your browser windows are not maximized or on > > portrait > > screens (tablets, phones)... so that is why I did this. > > > > Making pages too wide (expand so they fill a maximize screen) generally > > makes > > line reading harder (there is a reason newspapers etc. use narrow > > columns), thus > > why limiting the width of content tended to make for nicer presentation. > > And > > dokuwiki was all about presenting the front of "enlightenment.org" nicely > > to > > the world, so that's why I limited the width. I wasn't going to spend > > unlimited > > time on doing the www layout, design and content so I had to make > > compromises > > of work vs result. If i could get css/whatever to columnize layout somehow > > nicely across multiple screen sizes/types in dokuwiki it may have been a > > better > > solution. But time and effort. > > > > Anyway - that's why i did it and what i think about the TOC thing. > > > > > Frustratingly it's a global config, though it can be turned off on a > > > per-page basis. We can tweak what is included (again globally) but I > > > thought I would get a feeling for whether anyone felt strongly about this > > > > That was part of the issue and why I just turned it off as I thought it was > > more pain than good (as above) for much of the site. I generally think if > > your > > page is so long you need a TOC... perhaps you should split it up into > > multiple > > pages? :) > > > > My thoughts on it anyway... > > > > > Thanks, > > > Andy > > > -- > > > http://andywilliams.me > > > http://ajwillia.ms > > > > > -- > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > ___ > > > enlightenment-devel mailing list > > > enlightenment-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > -- > > - Codito, ergo sum - "I code, t
Re: [E-devel] FOSDEM
On Wed, 08 Nov 2017 22:05:07 + Andrew Williams said: > Hi, > > I reckon stickers are a minimum :) not sure if we can afford more than that > to give away. > > I also wondered if we should get some new t-shirts - not to give away but > for a little branding and visibility. Would folk be willing to pay for > their own shirt? > > I was wondering about “Enlightenment” (with logo) on the front and maybe > “built on EFL” on the back :) Can we do more stylish than a t-shirt? Like... A proper collared shirt maybe with the logo embroidered? grey/black with white embroidery? :) > Looking forward to it, > Andy > On Mon, 23 Oct 2017 at 14:31, Philippe Caseiro wrote: > > > Hi !! > > > >Stand request posted ! > > > >Now, I will work on some goodies ! > > > >Some ideas or proposals ? > > > > Regards > > > > Le mercredi 11 octobre 2017 14:51:03 CEST, Philippe Caseiro a écrit : > > > Le mercredi 11 octobre 2017 13:19:42 CEST, Andrew Williams a écrit : > > >> Hi, > > >> > > >> Good shout! I think I could make it this year and would be happy to help > > >> with the stand and/or put forward a talk (probably around edi > > >> ;) or getting > > >> into efl). > > > > > > Great ! > > > > > >> > > >> One proviso: we would have to do it properly - some fixed > > >> demos, a story to > > >> tell and probably some stickers too... > > >> > > >> An empty table with a name behind us made me sad :( > > > > > > Yes me to this year we will try to have a nice stand ! > > > > > > > > > > -- > > Philippe Caseiro > > > > Responsable Cadoles Services & Solutions > > Ingénieur logiciels libres > > > > https://www.cadoles.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 > > > -- > http://andywilliams.me > http://ajwillia.ms > ------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - "I code, therefore I am" -- 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] [EGIT] [core/efl] master 01/01: elput - re-enable switches (power buttons, lid etc.)
On Wed, 08 Nov 2017 14:09:00 + Mike Blumenkrantz
said:
> On Wed, Nov 8, 2017 at 6:39 AM Carsten Haitzler
> wrote:
>
> > raster pushed a commit to branch master.
> >
> >
> > http://git.enlightenment.org/core/efl.git/commit/?id=7a7abb043add0af083c46305824d8c341daf2374
> >
> > commit 7a7abb043add0af083c46305824d8c341daf2374
> > Author: Carsten Haitzler (Rasterman)
> > Date: Tue Nov 7 11:04:03 2017 +0900
> >
> > elput - re-enable switches (power buttons, lid etc.)
> >
> > this is needed for devices that no longer produce aspi events for
> > these. otherwise good luck getting any event on lid open/close or on
> > pressing the power button. this also stops hiding switch events from
> > libinput and now you can get switch events to find lid or tablet mode
> > switching changes.
> >
> > @fix
> > ---
> > src/lib/elput/Elput.h | 27 +++
> > src/lib/elput/elput.c | 3 +++
> > src/lib/elput/elput_evdev.c | 37 -
> > 3 files changed, 54 insertions(+), 13 deletions(-)
> >
> > diff --git a/src/lib/elput/Elput.h b/src/lib/elput/Elput.h
> > index b05536130b..db62c52d10 100644
> > --- a/src/lib/elput/Elput.h
> > +++ b/src/lib/elput/Elput.h
> > @@ -38,6 +38,7 @@ typedef enum
> > ELPUT_DEVICE_CAPS_TABLET_TOOL = (1 << 3),
> > ELPUT_DEVICE_CAPS_TABLET_PAD = (1 << 4),
> > ELPUT_DEVICE_CAPS_GESTURE = (1 << 5),
> > + ELPUT_DEVICE_CAPS_SWITCH = (1 << 6),
> > } Elput_Device_Caps;
> >
> > /* opaque structure to represent an input manager */
> > @@ -112,6 +113,29 @@ typedef struct Elput_Event_Pointer_Motion
> > double dy_unaccel;
> > } Elput_Event_Pointer_Motion;
> >
> > +/** @since 1.21 */
> > +typedef enum
> > +{
> > + ELPUT_SWITCH_TYPE_LID = 1,
> > + ELPUT_SWITCH_TYPE_TABLET_MODE,
> > +} Elput_Switch_Type;
> > +
> > +/** @since 1.21 */
> > +typedef enum
> > +{
> > + ELPUT_SWITCH_STATE_OFF = 0,
> > + ELPUT_SWITCH_STATE_ON = 1,
> > +} Elput_Switch_State;
> > +
> > +/** @since 1.21 */
> > +typedef struct _Elput_Event_Switch
> > +{
> > + Elput_Device *device;
> > + uint64_t time_usec;
> > + Elput_Switch_Type type;
> > + Elput_Switch_State state;
> > +} Elput_Event_Switch;
> > +
> >
> > EAPI extern int ELPUT_EVENT_SEAT_CAPS;
> > EAPI extern int ELPUT_EVENT_SEAT_FRAME;
> > @@ -122,6 +146,9 @@ EAPI extern int ELPUT_EVENT_SESSION_ACTIVE;
> > /** @since 1.19 */
> > EAPI extern int ELPUT_EVENT_POINTER_MOTION;
> >
> > +/** @since 1.21 */
> > +EAPI extern int ELPUT_EVENT_SWITCH;
> > +
> > /**
> > * @file
> > * @brief Ecore functions for dealing with libinput
> > diff --git a/src/lib/elput/elput.c b/src/lib/elput/elput.c
> > index 9519129759 <(951)%20912-9759>..f3cda411ea 100644
> > --- a/src/lib/elput/elput.c
> > +++ b/src/lib/elput/elput.c
> > @@ -13,6 +13,7 @@ EAPI int ELPUT_EVENT_MODIFIERS_SEND = 0;
> > EAPI int ELPUT_EVENT_DEVICE_CHANGE = 0;
> > EAPI int ELPUT_EVENT_SESSION_ACTIVE = 0;
> > EAPI int ELPUT_EVENT_POINTER_MOTION = 0;
> > +EAPI int ELPUT_EVENT_SWITCH = 0;
> > EAPI int elput_event_session_ready = 0;
> >
> > EAPI int
> > @@ -41,6 +42,7 @@ elput_init(void)
> > ELPUT_EVENT_DEVICE_CHANGE = ecore_event_type_new();
> > ELPUT_EVENT_SESSION_ACTIVE = ecore_event_type_new();
> > ELPUT_EVENT_POINTER_MOTION = ecore_event_type_new();
> > +ELPUT_EVENT_SWITCH = ecore_event_type_new();
> > elput_event_session_ready = ecore_event_type_new();
> > }
> >
> > @@ -71,6 +73,7 @@ elput_shutdown(void)
> >ELPUT_EVENT_DEVICE_CHANGE,
> >ELPUT_EVENT_SESSION_ACTIVE,
> >ELPUT_EVENT_POINTER_MOTION,
> > + ELPUT_EVENT_SWITCH,
> >elput_event_session_ready);
> >
> > eina_log_domain_unregister(_elput_log_dom);
> > diff --git a/src/lib/elput/elput_evdev.c b/src/lib/elput/elput_evdev.c
> > index 09d75932f8..afa42df68c 100644
> > --- a/src/lib/elput/elput_evdev.c
> > +++ b/src/lib/elput/elput_evdev.c
> > @@ -1595,6 +1595,20 @@ _tablet_tool_tip(struct libinput_device *idev,
> > struct libinput_event_tablet_tool
> > _pointer_button_send(dev, press[state]);
> > }
> >
> > +static void
> > +_switch_tog
Re: [E-devel] Git Feature/ Proposal
; > > 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 > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- 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] [EGIT] [core/enlightenment] master 05/10: use E_BITFIELD define for bitfield struct members
On Tue, 07 Nov 2017 07:45:50 -0800 Mike Blumenkrantz said: I'm curious... what was hard about debugging bitfields? at least in gdb: p blah->exists if it's a bitfield will do the right thing... as will printing the struct... p *blah ? what was hard? > discomfitor pushed a commit to branch master. > > http://git.enlightenment.org/core/enlightenment.git/commit/?id=59fa0e418dc78abc2d9e35635e44197ac8091520 > > commit 59fa0e418dc78abc2d9e35635e44197ac8091520 > Author: Mike Blumenkrantz > Date: Mon Nov 6 12:46:08 2017 -0500 > > use E_BITFIELD define for bitfield struct members > > on release builds this will be a bitfield, on devel builds it will make > bools a normal unsigned char for easier debugging > --- > src/bin/e_bindings.h | 20 +- > src/bin/e_client.h| 368 ++ > +--- src/bin/e_comp.h | 20 +- > src/bin/e_comp_object.h | 2 +- > src/bin/e_comp_wl.h | 58 ++--- > src/bin/e_comp_wl_data.h | 6 +- > src/bin/e_comp_x.h| 60 ++--- > src/bin/e_config_dialog.h | 14 +- > src/bin/e_confirm_dialog.h| 2 +- > src/bin/e_desk.h | 4 +- > src/bin/e_desklock.h | 2 +- > src/bin/e_dialog.h| 2 +- > src/bin/e_dnd.h | 10 +- > src/bin/e_exec.h | 4 +- > src/bin/e_fm.h| 52 ++--- > src/bin/e_fm_op_registry.h| 4 +- > src/bin/e_gadcon.h| 26 +-- > src/bin/e_gadcon_popup.h | 8 +- > src/bin/e_ilist.h | 6 +- > src/bin/e_macros.h| 6 + > src/bin/e_menu.h | 30 +-- > src/bin/e_module.h| 6 +- > src/bin/e_object.h| 6 +- > src/bin/e_pointer.h | 10 +- > src/bin/e_randr2.h| 22 +- > src/bin/e_remember.h | 2 +- > src/bin/e_shelf.h | 18 +- > src/bin/e_sys.h | 2 +- > src/bin/e_zone.h | 12 +- > src/modules/battery/e_mod_main.h | 8 +- > src/modules/luncher/luncher.h | 4 +- > src/modules/music-control/private.h | 4 +- > src/modules/notification/e_mod_main.h | 2 +- > src/modules/sysinfo/batman/batman.h | 8 +- > src/modules/sysinfo/sysinfo.h | 4 +- > src/modules/teamwork/e_mod_main.h | 6 +- > src/modules/temperature/e_mod_main.h | 4 +- > src/modules/vkbd/e_kbd_buf.h | 4 +- > src/modules/vkbd/e_kbd_int.h | 26 +-- > src/modules/wireless/wireless.h | 4 +- > src/modules/wl_desktop_shell/e_mod_main.h | 6 +- > 41 files changed, 434 insertions(+), 428 deletions(-) > > diff --git a/src/bin/e_bindings.h b/src/bin/e_bindings.h > index 940cac120..0bc9892a1 100644 > --- a/src/bin/e_bindings.h > +++ b/src/bin/e_bindings.h > @@ -51,10 +51,10 @@ struct E_Binding_Event_Mouse_Button > > unsigned int modifiers; /**< modifier keys pressed during the event */ > unsigned int timestamp; > - Eina_Bool double_click : 1; > - Eina_Bool triple_click : 1; > - Eina_Bool hold : 1; > - Eina_Bool scroll : 1; > + Eina_Bool double_click E_BITFIELD; > + Eina_Bool triple_click E_BITFIELD; > + Eina_Bool hold E_BITFIELD; > + Eina_Bool scroll E_BITFIELD; > }; > > struct E_Binding_Event_Wheel > @@ -73,7 +73,7 @@ struct _E_Binding_Mouse > E_Binding_Context ctxt; > int button; > E_Binding_Modifier mod; > - unsigned char any_mod : 1; > + unsigned char any_mod E_BITFIELD; > const char *action; > const char *params; > }; > @@ -83,7 +83,7 @@ struct _E_Binding_Key > E_Binding_Context ctxt; > const char *key; > E_Binding_Modifier mod; > - unsigned char any_mod : 1; > + unsigned char any_mod E_BITFIELD; > const char *action; > const char *params; > }; > @@ -98,8 +98,8 @@ struct _E_Binding_Edge > > float delay; > Ecore_Timer *timer; > - Eina_Bool any_mod : 1; > - Eina_Bool drag_only : 1; > + Eina_Bool any_mod E_BITFIELD; > + Eina_Bool drag_only E_BITFIELD; > }; > > struct _E_Binding_Signal > @@ -108,7 +108,7 @@ struct _E_Binding_Signal > const char *sig; > const char *src; > E_Binding_Modifier mod; > - unsigned char any_mod : 1; > + unsigned char any_mod E_BITFIELD; > const char *action; > const char *params; > }; > @@ -119,7 +119,7 @@ struct _E_Binding_Wheel > int direction; > int z; > E_Binding_Modifier mod; > - unsigned char any_mod : 1; > + unsigned char any_mod E_BITFIELD; > const char *action; > const char *params; > }; > diff --git a/src/bin/e_client.h b/s
Re: [E-devel] [EGIT] [core/enlightenment] master 05/10: use E_BITFIELD define for bitfield struct members
On Wed, 8 Nov 2017 19:36:24 -0500 Michael Blumenkrantz said: > You can't accurately set a watchpoint on a bitfield. h that. i have tried watch points many times and they never worked (for non-bitfields). i gave up on them long ago after many tries > On Thu, 9 Nov 2017 09:20:17 +0900 > Carsten Haitzler wrote: > > > On Tue, 07 Nov 2017 07:45:50 -0800 Mike Blumenkrantz > > said: > > > > I'm curious... what was hard about debugging bitfields? at least in gdb: > > > > p blah->exists > > > > if it's a bitfield will do the right thing... as will printing the struct... > > > > p *blah > > > > ? what was hard? > > > > > discomfitor pushed a commit to branch master. > > > > > > http://git.enlightenment.org/core/enlightenment.git/commit/?id=59fa0e418dc78abc2d9e35635e44197ac8091520 > > > > > > commit 59fa0e418dc78abc2d9e35635e44197ac8091520 > > > Author: Mike Blumenkrantz > > > Date: Mon Nov 6 12:46:08 2017 -0500 > > > > > > use E_BITFIELD define for bitfield struct members > > > > > > on release builds this will be a bitfield, on devel builds it will > > > make bools a normal unsigned char for easier debugging > > > --- > > > src/bin/e_bindings.h | 20 +- > > > src/bin/e_client.h| 368 ++ > > > +--- src/bin/e_comp.h | 20 +- > > > src/bin/e_comp_object.h | 2 +- > > > src/bin/e_comp_wl.h | 58 ++--- > > > src/bin/e_comp_wl_data.h | 6 +- > > > src/bin/e_comp_x.h| 60 ++--- > > > src/bin/e_config_dialog.h | 14 +- > > > src/bin/e_confirm_dialog.h| 2 +- > > > src/bin/e_desk.h | 4 +- > > > src/bin/e_desklock.h | 2 +- > > > src/bin/e_dialog.h| 2 +- > > > src/bin/e_dnd.h | 10 +- > > > src/bin/e_exec.h | 4 +- > > > src/bin/e_fm.h| 52 ++--- > > > src/bin/e_fm_op_registry.h| 4 +- > > > src/bin/e_gadcon.h| 26 +-- > > > src/bin/e_gadcon_popup.h | 8 +- > > > src/bin/e_ilist.h | 6 +- > > > src/bin/e_macros.h| 6 + > > > src/bin/e_menu.h | 30 +-- > > > src/bin/e_module.h| 6 +- > > > src/bin/e_object.h| 6 +- > > > src/bin/e_pointer.h | 10 +- > > > src/bin/e_randr2.h| 22 +- > > > src/bin/e_remember.h | 2 +- > > > src/bin/e_shelf.h | 18 +- > > > src/bin/e_sys.h | 2 +- > > > src/bin/e_zone.h | 12 +- > > > src/modules/battery/e_mod_main.h | 8 +- > > > src/modules/luncher/luncher.h | 4 +- > > > src/modules/music-control/private.h | 4 +- > > > src/modules/notification/e_mod_main.h | 2 +- > > > src/modules/sysinfo/batman/batman.h | 8 +- > > > src/modules/sysinfo/sysinfo.h | 4 +- > > > src/modules/teamwork/e_mod_main.h | 6 +- > > > src/modules/temperature/e_mod_main.h | 4 +- > > > src/modules/vkbd/e_kbd_buf.h | 4 +- > > > src/modules/vkbd/e_kbd_int.h | 26 +-- > > > src/modules/wireless/wireless.h | 4 +- > > > src/modules/wl_desktop_shell/e_mod_main.h | 6 +- > > > 41 files changed, 434 insertions(+), 428 deletions(-) > > > > > > diff --git a/src/bin/e_bindings.h b/src/bin/e_bindings.h > > > index 940cac120..0bc9892a1 100644 > > > --- a/src/bin/e_bindings.h > > > +++ b/src/bin/e_bindings.h > > > @@ -51,10 +51,10 @@ struct E_Binding_Event_Mouse_Button > > > > > > unsigned int modifiers; /**< modifier keys pressed during the event */ > > > unsigned int timestamp; > > > - Eina_Bool double_click : 1; > > > - Eina_Bool triple_click : 1; > > > - Eina_Bool hold : 1; > > > - Eina_Bool scroll : 1; > > > + Eina_Bool double_click E_BITFIELD; > > > + Eina_Bool triple_click E_BITFIELD; > > > +
Re: [E-devel] Probie proposal: Taxi2se
On Fri, 10 Nov 2017 11:47:36 +0900 Jean-Philippe André said: > Hello, > > I would like to propose Sungtaek Hong aka taxi2se for probie access. ++ > He's been working mostly on elementary features, has just a few commits in > master but recently he's been involved in some core stuff for elementary. > > I would like to offer him a probie access in part because this would make > *my* life easier reviewing and merging his patches. For instance D5364 (elm > theme for eo) or D5151 (bg part for all widgets in eo) are large patches > made of multiple commits. > > I also believe he is fully able to contribute well to EFL and hope that > this access would encourage him to do even more ^^ > > Unless there is a strong opposition, I'll add him on Monday. > > Best regards, > > -- > Jean-Philippe André > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - "I code, therefore I am" -- 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] [EGIT] [core/efl] master 01/01: Revert "Edje: use textblock by default"
On Sat, 11 Nov 2017 09:47:46 +0200 Daniel Hirt said: > Hi, > > On 11/11/2017 05:21 AM, Carsten Haitzler wrote: > > [snipped] > > This breaks E. pager ono my right screen looks like: > > > > http://devs.enlightenment.org/~raster/shot-2017-11-11_12-13-14.png > > > > Thanks. Is there anything else to observe here other than the CPU usage? the squashed pager no... but see below > > on my left screen shellf keeps swapping between 2 dizes wobbling back > > and forth every frame eating cpu and making it "blurry"... > > > > Hmmm... Not sure how to reproduce this. Do I need two screens? What > widgets in the shelf are doing that? i literally see the shelf get 5 pixels wider, then next frame 5 pixels narrower and repeat every frame at 60hz... > > note - theme is the flat one in devs/raster/theme/flat2 branch. so > > this change certainly breaks something... > > This work is based on the default theme and there is no apparent odd > behavior here even when using shelves on two different screens (laptop + > monitor). correct. based off default and nothing weird there. especially not with the pager... and it's squashed. it seems like something in your patches has affected min size calc maybe... > Also, I can't build the theme from your branch, as some files seem to be > missing. This is the first error I get: >make[2]: *** No rule to make target 'elementary/themes/edc/sys.edc', > needed by 'elementary/themes/default.edj'. Stop. eh? ummm... 12:04AM ~/C/th-efl/data ⎇ devs/raster/theme/flat2 ⚡ 1 > git status elementary/themes/edc/sys.edc On branch devs/raster/theme/flat2 Your branch is up to date with 'origin/devs/raster/theme/flat2'. nothing to commit, working tree clean. it's committed. > Thanks for the feedback. Let's try to get it reproduced on my machine so > I can fix it and get it back on master. > > > [snipped] > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- 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] [EGIT] [core/efl] master 01/01: Revert "Edje: use textblock by default"
On Sat, 11 Nov 2017 19:35:02 +0200 Daniel Hirt said: > Hi, > > On 11/11/2017 05:06 PM, Carsten Haitzler wrote: > > [snipped] > > 12:04AM ~/C/th-efl/data ⎇ devs/raster/theme/flat2 ⚡ 1 > git status > > elementary/themes/edc/sys.edc On branch devs/raster/theme/flat2 > > Your branch is up to date with 'origin/devs/raster/theme/flat2'. > > > > nothing to commit, working tree clean. it's committed. > > > > The following (with the "nothere" file) shows the same output: > > ➜ efl git:(devs/raster/theme/flat2) ✗ git status nothere > On branch devs/raster/theme/flat2 > Your branch is up to date with 'origin/devs/raster/theme/flat2'. > > nothing to commit, working tree clean > > It looks like it (maybe more) were removed with: > 6e867dd66a6f2abb3981781c0ce44df9e101aed7 > > A quick search suggests the following usage (see output): > > ➜ efltmp git:(devs/raster/theme/flat2) git ls-files --error-unmatch > data/elementary/themes/edc/sys.edc > error: pathspec 'data/elementary/themes/edc/sys.edc' did not match any > file(s) known to git. > Did you forget to 'git add'? hmmm indeed its not there. i'm not actually building the theme with make. i just have a script that only builds that theme and nothing else. much faster: cd ~/C/th-efl/data/elementary/themes/ edje_cc \ -id ./img -id ./fdo -fd ./fnt -sd ./snd \ -l ~/C/th-efl/COPYING \ -a ~/C/th-efl/AUTHORS \ -fastdecomp default.edc echo "... Installing" sudo install default.edj $P/share/elementary/themes/default.edj try that. > Best, >Danny. > > > [snipped] > -- - Codito, ergo sum - "I code, therefore I am" -- 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] [EGIT] [core/efl] master 01/01: elput - re-enable switches (power buttons, lid etc.)
On Sun, 12 Nov 2017 11:33:28 +0100 marcel-hollerb...@t-online.de said:
> Hello,
>
> in configure.ac we check for libinput 0.8 but this api is added in 1.6
> so we should require now 1.6 ?
indeed we should. in fact the checks are a bit messy. we still checked for
0.6.0 too... and we dealt with an api change at 0.8 ... time to just require
1.6. it came out jan 2017 .. so it's pushing on a year old. at least for
wayland kind of stuff needing bleeding edge things it pretty normal.
> On Wed, Nov 08, 2017 at 03:39:11AM -0800, Carsten Haitzler wrote:
> > raster pushed a commit to branch master.
> >
> > http://git.enlightenment.org/core/efl.git/commit/?id=7a7abb043add0af083c46305824d8c341daf2374
> >
> > commit 7a7abb043add0af083c46305824d8c341daf2374
> > Author: Carsten Haitzler (Rasterman)
> > Date: Tue Nov 7 11:04:03 2017 +0900
> >
> > elput - re-enable switches (power buttons, lid etc.)
> >
> > this is needed for devices that no longer produce aspi events for
> > these. otherwise good luck getting any event on lid open/close or on
> > pressing the power button. this also stops hiding switch events from
> > libinput and now you can get switch events to find lid or tablet mode
> > switching changes.
> >
> > @fix
> > ---
> > src/lib/elput/Elput.h | 27 +++
> > src/lib/elput/elput.c | 3 +++
> > src/lib/elput/elput_evdev.c | 37 -
> > 3 files changed, 54 insertions(+), 13 deletions(-)
> >
> > diff --git a/src/lib/elput/Elput.h b/src/lib/elput/Elput.h
> > index b05536130b..db62c52d10 100644
> > --- a/src/lib/elput/Elput.h
> > +++ b/src/lib/elput/Elput.h
> > @@ -38,6 +38,7 @@ typedef enum
> > ELPUT_DEVICE_CAPS_TABLET_TOOL = (1 << 3),
> > ELPUT_DEVICE_CAPS_TABLET_PAD = (1 << 4),
> > ELPUT_DEVICE_CAPS_GESTURE = (1 << 5),
> > + ELPUT_DEVICE_CAPS_SWITCH = (1 << 6),
> > } Elput_Device_Caps;
> >
> > /* opaque structure to represent an input manager */
> > @@ -112,6 +113,29 @@ typedef struct Elput_Event_Pointer_Motion
> > double dy_unaccel;
> > } Elput_Event_Pointer_Motion;
> >
> > +/** @since 1.21 */
> > +typedef enum
> > +{
> > + ELPUT_SWITCH_TYPE_LID = 1,
> > + ELPUT_SWITCH_TYPE_TABLET_MODE,
> > +} Elput_Switch_Type;
> > +
> > +/** @since 1.21 */
> > +typedef enum
> > +{
> > + ELPUT_SWITCH_STATE_OFF = 0,
> > + ELPUT_SWITCH_STATE_ON = 1,
> > +} Elput_Switch_State;
> > +
> > +/** @since 1.21 */
> > +typedef struct _Elput_Event_Switch
> > +{
> > + Elput_Device *device;
> > + uint64_t time_usec;
> > + Elput_Switch_Type type;
> > + Elput_Switch_State state;
> > +} Elput_Event_Switch;
> > +
> >
> > EAPI extern int ELPUT_EVENT_SEAT_CAPS;
> > EAPI extern int ELPUT_EVENT_SEAT_FRAME;
> > @@ -122,6 +146,9 @@ EAPI extern int ELPUT_EVENT_SESSION_ACTIVE;
> > /** @since 1.19 */
> > EAPI extern int ELPUT_EVENT_POINTER_MOTION;
> >
> > +/** @since 1.21 */
> > +EAPI extern int ELPUT_EVENT_SWITCH;
> > +
> > /**
> > * @file
> > * @brief Ecore functions for dealing with libinput
> > diff --git a/src/lib/elput/elput.c b/src/lib/elput/elput.c
> > index 9519129759..f3cda411ea 100644
> > --- a/src/lib/elput/elput.c
> > +++ b/src/lib/elput/elput.c
> > @@ -13,6 +13,7 @@ EAPI int ELPUT_EVENT_MODIFIERS_SEND = 0;
> > EAPI int ELPUT_EVENT_DEVICE_CHANGE = 0;
> > EAPI int ELPUT_EVENT_SESSION_ACTIVE = 0;
> > EAPI int ELPUT_EVENT_POINTER_MOTION = 0;
> > +EAPI int ELPUT_EVENT_SWITCH = 0;
> > EAPI int elput_event_session_ready = 0;
> >
> > EAPI int
> > @@ -41,6 +42,7 @@ elput_init(void)
> > ELPUT_EVENT_DEVICE_CHANGE = ecore_event_type_new();
> > ELPUT_EVENT_SESSION_ACTIVE = ecore_event_type_new();
> > ELPUT_EVENT_POINTER_MOTION = ecore_event_type_new();
> > +ELPUT_EVENT_SWITCH = ecore_event_type_new();
> > elput_event_session_ready = ecore_event_type_new();
> > }
> >
> > @@ -71,6 +73,7 @@ elput_shutdown(void)
> >ELPUT_EVENT_DEVICE_CHANGE,
> >ELPUT_EVENT_SESSION_ACTIVE,
> >ELPUT_EVENT_POINTER_MOTION,
> > + ELPUT_EVENT_SWITCH,
> >elput_event_session_ready);
> >
> > eina_log_domain_unregister(_elput_log_dom);
Re: [E-devel] [EGIT] [core/efl] master 01/01: calendar: Remove invalid ref to elm enum
On Mon, 13 Nov 2017 13:47:28 +0200 Daniel Zaoui said:
> Thanks for the fix. And for having excited my curiosity. I didn't know that
> US, Canada... consider Sunday as the first day. Always good to know.
They are just being silly. Monday is of course! :)
> On Mon, 13 Nov 2017 02:40:37 -0800
> Jean-Philippe ANDRÉ wrote:
>
> > jpeg pushed a commit to branch master.
> >
> > http://git.enlightenment.org/core/efl.git/commit/?id=4255c34f7a8dfcba7fe585fd773fa6f9157f2829
> >
> > commit 4255c34f7a8dfcba7fe585fd773fa6f9157f2829
> > Author: Jean-Philippe Andre
> > Date: Mon Nov 13 15:39:53 2017 +0900
> >
> > calendar: Remove invalid ref to elm enum
> >
> > Thanks @JackDanielz for the report. This does not solve your
> > actual concern, though.
> > ---
> > src/lib/elementary/efl_ui_calendar.eo | 13 +++--
> > 1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/src/lib/elementary/efl_ui_calendar.eo
> > b/src/lib/elementary/efl_ui_calendar.eo index 43d4508516..5125f2e9cd
> > 100644 --- a/src/lib/elementary/efl_ui_calendar.eo
> > +++ b/src/lib/elementary/efl_ui_calendar.eo
> > @@ -26,13 +26,14 @@ class Efl.Ui.Calendar (Efl.Ui.Layout,
> > Efl.Ui.Focus.Composition, Elm.Interface.At ]]
> > methods {
> >@property first_day_of_week {
> > - [[The first day of week to use on calendar widgets'.]]
> > - set {
> > - }
> > - get {
> > - }
> > + [[The first day of week to use on calendar widgets.
> > +
> > + This is the day that will appear in the left-most column
> > (eg. Monday
> > + in France or Sunday in the US).
> > + ]]
> > values {
> > -day:
> > Efl.Ui.Calendar.Weekday(Efl.Ui.Calendar.Weekday.sunday); [[Weekday
> > enum value, see @Elm.Calendar.Weekday]]
> > +day:
> > Efl.Ui.Calendar.Weekday(Efl.Ui.Calendar.Weekday.sunday);
> > + [[The first day of the week.]]
> > }
> >}
> >@property date_min {
> >
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
- Codito, ergo sum - "I code, therefore I am" --
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] [EGIT] [core/efl] master 01/01: calendar: Remove invalid ref to elm enum
On Mon, 13 Nov 2017 23:24:09 +0200 Daniel Zaoui said:
> Well, sorry to disagree with you :P My first day is Sunday.
:-P
> On Tue, 14 Nov 2017 00:11:44 +0900
> Carsten Haitzler wrote:
>
> > On Mon, 13 Nov 2017 13:47:28 +0200 Daniel Zaoui
> > said:
> >
> > > Thanks for the fix. And for having excited my curiosity. I didn't
> > > know that US, Canada... consider Sunday as the first day. Always
> > > good to know.
> >
> > They are just being silly. Monday is of course! :)
> >
> > > On Mon, 13 Nov 2017 02:40:37 -0800
> > > Jean-Philippe ANDRÉ wrote:
> > >
> > > > jpeg pushed a commit to branch master.
> > > >
> > > > http://git.enlightenment.org/core/efl.git/commit/?id=4255c34f7a8dfcba7fe585fd773fa6f9157f2829
> > > >
> > > > commit 4255c34f7a8dfcba7fe585fd773fa6f9157f2829
> > > > Author: Jean-Philippe Andre
> > > > Date: Mon Nov 13 15:39:53 2017 +0900
> > > >
> > > > calendar: Remove invalid ref to elm enum
> > > >
> > > > Thanks @JackDanielz for the report. This does not solve your
> > > > actual concern, though.
> > > > ---
> > > > src/lib/elementary/efl_ui_calendar.eo | 13 +++--
> > > > 1 file changed, 7 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/src/lib/elementary/efl_ui_calendar.eo
> > > > b/src/lib/elementary/efl_ui_calendar.eo index
> > > > 43d4508516..5125f2e9cd 100644 ---
> > > > a/src/lib/elementary/efl_ui_calendar.eo +++
> > > > b/src/lib/elementary/efl_ui_calendar.eo @@ -26,13 +26,14 @@ class
> > > > Efl.Ui.Calendar (Efl.Ui.Layout, Efl.Ui.Focus.Composition,
> > > > Elm.Interface.At ]] methods {
> > > >@property first_day_of_week {
> > > > - [[The first day of week to use on calendar widgets'.]]
> > > > - set {
> > > > - }
> > > > - get {
> > > > - }
> > > > + [[The first day of week to use on calendar widgets.
> > > > +
> > > > + This is the day that will appear in the left-most
> > > > column (eg. Monday
> > > > + in France or Sunday in the US).
> > > > + ]]
> > > > values {
> > > > -day:
> > > > Efl.Ui.Calendar.Weekday(Efl.Ui.Calendar.Weekday.sunday); [[Weekday
> > > > enum value, see @Elm.Calendar.Weekday]]
> > > > +day:
> > > > Efl.Ui.Calendar.Weekday(Efl.Ui.Calendar.Weekday.sunday);
> > > > + [[The first day of the week.]]
> > > > }
> > > >}
> > > >@property date_min {
> > > >
> > >
> > >
> > > --
> > > 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
--
- Codito, ergo sum - "I code, therefore I am" --
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] .eo.c to .eo.x
On Tue, 14 Nov 2017 14:51:38 -0200 Gustavo Sverzut Barbieri said: > On Tue, Nov 14, 2017 at 9:35 AM, wrote: > > On Tue, Nov 14, 2017 at 09:22:01AM -0200, Gustavo Sverzut Barbieri wrote: > >> while I'm okay with .eo.x, I'm not sure you should include it in > >> "sources", rather do in "dependencies". > > > > Well is it a dependency? > > that's exactly what it is: a dependency. > > it's not the source file, which is the .c that devs edit :-) Rather > the ".eo" is a source, but the complier doesn't understand it, so we > translate so it can be used by c compiler... in an ideal world we > could provide "efl_cpp" that wraps cpp and would generate C for you > transparently. This is what I originally was proposing we do for eo. We provide basically a smarter "cpp" that runs before the real compiler. It could, like ccache, distcc etc. just wrap the real compile command. It'd also allow us to be far more elegant. We'd have created a hybrid "language" or essentially custom compiler with extensions of course - C as the base with our own extensions that are done as a CPP phase and generating C as output rather than inside the core compiler generating ASM or whatever intermediate stage comes out prior to the binary. But no one wanted it. :( > >> as for generating .eo.c and .eo.h independently (mentioned in another > >> email in this thread), don't go that route plz... slows down the > >> process quite a lot :-/ > > > > Even if i dont like the argument, right now its the same ... :) > > huh? when one .eo changes, every other file changes the same way. > There is no point to process it 3 times, it's even race-prone... > > -- > Gustavo Sverzut Barbieri > -- > Mobile: +55 (16) 99354-9890 > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- 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] .eo.c to .eo.x
On Tue, 14 Nov 2017 14:49:01 -0200 Gustavo Sverzut Barbieri said: > On Tue, Nov 14, 2017 at 10:46 AM, Andrew Williams > wrote: > > Hi, > > > > Actually my custom rule will install correctly as th .eo.h file is the only > > declared output and so no other files are installed. In this way you can > > generate all three files in one eolian_gen pass which is much faster. > > this is what I expect, not parsing every file again, building the same > in memory db again, just to generate different output. > > actually I'd expect one day eolian get some caching in mmap-able > format, making each ".eo" processed in the cache, would speed up a lot > the efl build. I actually suspect that that caching (at least a transparent automatic cache) won't help much because to validate the cache you have to at least stat every single eo file that would normally be parsed first and then compare to cache timestamp. that's going to consume a lot of the overhead alone. If we could avoid this, it'd be better. Perhaps it'd be better to actually have a "system cache". Whenever you install .eo files, after the install of all of them is done, as root run "eolian_cache_update" and it will update maybe /var/cache/eloian-cache.eet or something. Then this is done manually after an install or as a post-install make rule etc. and at least it can cover "system eo files". -- - Codito, ergo sum - "I code, therefore I am" -- 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] [EGIT] [core/efl] master 01/01: Revert series of patches from cedric (due to dependencies and conflicts)
On Tue, 14 Nov 2017 18:52:44 -0800 Carsten Haitzler said: Hey cedric please TEST STUFF! :) Kind regards. The Enlightenment testing bot. > raster pushed a commit to branch master. > > http://git.enlightenment.org/core/efl.git/commit/?id=2cea85db388d34337676466ef7f50c22e685c7d0 > > commit 2cea85db388d34337676466ef7f50c22e685c7d0 > Author: Carsten Haitzler (Rasterman) > Date: Wed Nov 15 11:48:25 2017 +0900 > > Revert series of patches from cedric (due to dependencies and conflicts) > > Revert "elementary: currently double declare elm_init/shutdown." > This reverts commit 44bb0c18480f5094fcd0c8be93de87be5c1d78c5. > Revert "elementary: fix efl_ui_multibutton installed headers." > This reverts commit 32a213dc722be2bfec5fb2b513dd556cfb7e9f33. > Revert "elementary: introduce Efl_Ui.h." > This reverts commit df3d3f7334a79f1ab661b31787002f50af59b3f3. > Revert "ecore: do not display error message on cancel." > This reverts commit 99654b7cd29b418e0308be350c8d26208c0905a8. > Revert "efl: and don't forget to install the new dependencies." > This reverts commit 814ffb9b6bd50d498bfd98f4b8a75f1cad3cc0cf. > Revert "ecore: remove EFL_OBJECT_BETA as Efl_Core.h is for Efl new > inerfaces." This reverts commit 619d0f3cff023414feb8f2aaeebf468806c50b44. > Revert "ecore: move EAPI_MAIN from elementary to ecore." > This reverts commit e5d84da864214b9f772808040f22e1614889a25f. > > as such commit e5d84da864214b9f772808040f22e1614889a25f starts the > breaking. enlightenment, terminologya and other apps can't compile > against that efl anymore. 619d0f3cff023414feb8f2aaeebf468806c50b44 > then makes this even worse with even more header errors and undefined > types. on top of this df3d3f7334a79f1ab661b31787002f50af59b3f3 then > starts making elementary_test segfault when it runs. it wont even > start up. > > asu such of these 7 commits in the first 4 (that are then relied on > later) 3 of these first 4 cause serious breakage. this simply is a > complete lack of testing changes, so i've rolled fl back to before > these things so it builds and works again and you can build against it. > > PLEASE test these things. this looks ot me to be obviously a lack of > any testing... :( > --- > Makefile.am| 5 +- > configure.ac | 1 - > pc/.gitignore | 1 - > pc/efl-ui.pc.in| 20 -- > src/Makefile_Elementary.am | 4 +- > src/lib/ecore/Efl_Core.h | 4 +- > src/lib/ecore/efl_general.h| 17 -- > src/lib/elementary/Efl_Ui.h| 253 > - src/lib/elementary/Elementary.h| > 4 + src/lib/elementary/efl_ui_multibuttonentry.h | 1 + > src/lib/elementary/elm_general.h | 4 +- > .../ecore/system/upower/ecore_system_upower.c | 9 +- > 12 files changed, 16 insertions(+), 307 deletions(-) > > diff --git a/Makefile.am b/Makefile.am > index 8fb921c734..1106b60b01 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -136,9 +136,7 @@ pc/emile.pc \ > pc/eet.pc \ > pc/evas.pc \ > pc/ecore.pc \ > -pc/efl-core.pc \ > pc/ecore-con.pc \ > -pc/efl-net.pc \ > pc/ecore-ipc.pc \ > pc/ecore-file.pc \ > pc/ecore-input.pc \ > @@ -159,8 +157,7 @@ pc/emotion.pc \ > pc/ethumb.pc \ > pc/ethumb_client.pc \ > pc/elocation.pc \ > -pc/elementary.pc \ > -pc/efl-ui.pc > +pc/elementary.pc > > if HAVE_CXX11 > pkgconfig_DATA += \ > diff --git a/configure.ac b/configure.ac > index 003190ba26..ba9b78318e 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -5606,7 +5606,6 @@ pc/efl-cxx.pc > pc/efl-wl.pc > pc/efl-core.pc > pc/efl-net.pc > -pc/efl-ui.pc > pc/evas-fb.pc > pc/evas-eglfs.pc > pc/evas-opengl-x11.pc > diff --git a/pc/.gitignore b/pc/.gitignore > index 5657ab6a68..5e87ab1e64 100644 > --- a/pc/.gitignore > +++ b/pc/.gitignore > @@ -76,4 +76,3 @@ > /efl-wl.pc > /efl-core.pc > /efl-net.pc > -/efl-ui.pc > \ No newline at end of file > diff --git a/pc/efl-ui.pc.in b/pc/efl-ui.pc.in > deleted file mode 100644 > index 04c9dcf472..00 > --- a/pc/efl-ui.pc.in > +++ /dev/null > @@ -1,20 +0,0 @@ > -prefix=@prefix@ > -exec_prefix=@exec_prefix@ > -libdir=@libdir@ > -includedir=@includedir@ > -datarootdir=@datarootdir@ > -datadir=@datadir@/elementary > -pkgdatadir=@datadir@/elem
Re: [E-devel] .eo.c to .eo.x
On Wed, 15 Nov 2017 12:35:52 -0200 Gustavo Sverzut Barbieri said: > On Tue, Nov 14, 2017 at 10:37 PM, Carsten Haitzler > wrote: > > On Tue, 14 Nov 2017 14:51:38 -0200 Gustavo Sverzut Barbieri > > said: > > > >> On Tue, Nov 14, 2017 at 9:35 AM, wrote: > >> > On Tue, Nov 14, 2017 at 09:22:01AM -0200, Gustavo Sverzut Barbieri wrote: > >> >> while I'm okay with .eo.x, I'm not sure you should include it in > >> >> "sources", rather do in "dependencies". > >> > > >> > Well is it a dependency? > >> > >> that's exactly what it is: a dependency. > >> > >> it's not the source file, which is the .c that devs edit :-) Rather > >> the ".eo" is a source, but the complier doesn't understand it, so we > >> translate so it can be used by c compiler... in an ideal world we > >> could provide "efl_cpp" that wraps cpp and would generate C for you > >> transparently. > > > > This is what I originally was proposing we do for eo. We provide basically a > > smarter "cpp" that runs before the real compiler. It could, like ccache, > > distcc etc. just wrap the real compile command. It'd also allow us to be > > far more elegant. We'd have created a hybrid "language" or essentially > > custom compiler with extensions of course - C as the base with our own > > extensions that are done as a CPP phase and generating C as output rather > > than inside the core compiler generating ASM or whatever intermediate stage > > comes out prior to the binary. > > > > But no one wanted it. :( > > yeah, I proposed that... could do our "lambda" (ie: offer C++ lambda > in C), but rejected :-/ Let's have another round of caipirinhas. :) -- - Codito, ergo sum - "I code, therefore I am" -- 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] Improving web site accessibility
On Thu, 16 Nov 2017 23:38:05 + jaquilina said: > Hi guys this is something I can contribute to in terms of website. and I > can even host it if you all so desire. Question is do you want this > built off a framework, such as wordpress where it will be easy to > include a forums section or something custom built? We don't need hosting. We have that. We have a framework: Dokuwiki. Our content depends on it and its markdown. It also has discussion forums too. They are activated on several pages. This discussion is really about styling and maybe layout. > On 2017-11-16 22:26, Stephen Houston wrote: > > +1 I've been saying we need a new website bad. And one that is sleek, > > modern, and yes white. Time to look up to date and kept with the > > times. > > You will notice nearly every major linux distribution and nearly all > > major > > linux software websites are in the confines of what you describe. > > Simple, > > flat, white background and black text, sharp but small images that are > > mostly subtle, and responsive design to look good across devices. The > > reason being that this is proven to be the easiest on the eyes and the > > most > > pleasing to the reader as you said. > > > > On Thu, Nov 16, 2017, 3:58 PM Cedric Bail wrote: > > > >> Hi, > >> > >> As some of you may have noticed we are doing some improvement to our > >> documentation and trying to get things easier when starting with EFL. > >> One > >> of the main issue we are facing is that our website is definitively > >> hard to > >> read for a lot of people. So Paul went on trying to figure out why. > >> > >> The first problem is actually the constrast ratio between background > >> and > >> text. According to W3C accessibility guidelines ( > >> https://www.w3.org/TR/WCAG21/#contrast-minimum )it should be 4.5:1 at > >> least. Our colors are #818181 for the text and #303030 which give a > >> contrast ratio of 3.39:1 ( > >> https://webaim.org/resources/contrastchecker/ > >> ). And it is worth for people with vision impairment where it should > >> be 7:1. > >> > >> Black on white or white on black would work, but according to some > >> random > >> person on Internet (could not find a scientific evidence/citation of > >> it) a > >> white background force your pupils to contracts, making it easier to > >> focus > >> your eye with a smaller pupil (much like the depth of field is > >> increased > >> with a smaller camera lens). This could be shown by a test carried on > >> 136 > >> subject, where the people reading black text on a white background > >> scored > >> better than any other combination of colors ( > >> http://lite.mst.edu/media/research/ctel/documents/LITE-2003-04.pdf ). > >> > >> The second problem are our links that are difficult to tell wether > >> they > >> have been clicked on or not. Also they have a slight glow around the > >> links > >> that makes them harder to read. The best link on the subject we can > >> point > >> to would be > >> https://www.nngroup.com/articles/guidelines-for-visualizing-links/ . > >> > >> So it would be best to come up with a more accessible design for our > >> web > >> site. If someone want to suggest a new design within those constraint, > >> it > >> would be great, but I would suggest to look at > >> https://gstreamer.freedesktop.org/documentation/ or at > >> http://doc.qt.io/ > >> . They are simple and work well in term of readability. We could > >> easily go > >> with something like that. What do you think ? > >> > >> 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 > >> > > -- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >
Re: [E-devel] Improving web site accessibility
-- > > 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 > -- - Codito, ergo sum - "I code, therefore I am" -- 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] Improving web site accessibility
ist > >> 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 > -- - Codito, ergo sum - "I code, therefore I am" -- 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] Improving web site accessibility
On Fri, 17 Nov 2017 10:49:01 + Andrew Williams said:
> Wow, what happened in
> https://git.enlightenment.org/website/www.git/commit/?id=9f75e7370f168ada24267d6c065a9cbba92ee42f?
> We're all monochrome now :(
well i was doing the contrast thing. increasing it.
> a {
> - color: #44aaff;
> + color: #ee;
> }
>
> Pretty sure the comment about link colours was that clicked vs unclicked
> should be more differerent - no need to lose the nice blues completely.
> Looking at the site now it's lost most of it's character.
>
> Also, since we have source control, why are we leaving old code commented
> out?
>
> - text-shadow: 0px 0px 10px rgba(255, 255, 255, 0.5);
> + text-shadow: none;
> +// text-shadow: 0px 0px 10px rgba(255, 255, 255, 0.5);
i like doing this for things i might undo later or refer to.
> Andy
>
> On Fri, 17 Nov 2017 at 02:33 Carsten Haitzler wrote:
>
> > On Thu, 16 Nov 2017 23:38:05 + jaquilina
> > said:
> >
> > > Hi guys this is something I can contribute to in terms of website. and I
> > > can even host it if you all so desire. Question is do you want this
> > > built off a framework, such as wordpress where it will be easy to
> > > include a forums section or something custom built?
> >
> > We don't need hosting. We have that. We have a framework: Dokuwiki. Our
> > content
> > depends on it and its markdown. It also has discussion forums too. They are
> > activated on several pages.
> >
> > This discussion is really about styling and maybe layout.
> >
> > > On 2017-11-16 22:26, Stephen Houston wrote:
> > > > +1 I've been saying we need a new website bad. And one that is sleek,
> > > > modern, and yes white. Time to look up to date and kept with the
> > > > times.
> > > > You will notice nearly every major linux distribution and nearly all
> > > > major
> > > > linux software websites are in the confines of what you describe.
> > > > Simple,
> > > > flat, white background and black text, sharp but small images that are
> > > > mostly subtle, and responsive design to look good across devices. The
> > > > reason being that this is proven to be the easiest on the eyes and the
> > > > most
> > > > pleasing to the reader as you said.
> > > >
> > > > On Thu, Nov 16, 2017, 3:58 PM Cedric Bail wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> As some of you may have noticed we are doing some improvement to our
> > > >> documentation and trying to get things easier when starting with EFL.
> > > >> One
> > > >> of the main issue we are facing is that our website is definitively
> > > >> hard to
> > > >> read for a lot of people. So Paul went on trying to figure out why.
> > > >>
> > > >> The first problem is actually the constrast ratio between background
> > > >> and
> > > >> text. According to W3C accessibility guidelines (
> > > >> https://www.w3.org/TR/WCAG21/#contrast-minimum )it should be 4.5:1 at
> > > >> least. Our colors are #818181 for the text and #303030 which give a
> > > >> contrast ratio of 3.39:1 (
> > > >> https://webaim.org/resources/contrastchecker/
> > > >> ). And it is worth for people with vision impairment where it should
> > > >> be 7:1.
> > > >>
> > > >> Black on white or white on black would work, but according to some
> > > >> random
> > > >> person on Internet (could not find a scientific evidence/citation of
> > > >> it) a
> > > >> white background force your pupils to contracts, making it easier to
> > > >> focus
> > > >> your eye with a smaller pupil (much like the depth of field is
> > > >> increased
> > > >> with a smaller camera lens). This could be shown by a test carried on
> > > >> 136
> > > >> subject, where the people reading black text on a white background
> > > >> scored
> > > >> better than any other combination of colors (
> > > >> http://lite.mst.edu/media/research/ctel/documents/LITE-2003-04.pdf ).
> > > >>
> > > >> The second problem are our links that are difficult to tell wether
> > > >> they
> > > >> have been clicked on or not. Also they have a slight glow around the
> > > >>
Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: music-control - install properly with meson build with icon
On Sun, 19 Nov 2017 13:05:06 + Andrew Williams said:
> Hi,
>
> As the autotool/Makefiles are still in place I fixed the build for users
> not yet using the E meson build.
i was assuming autotools was dead - mike did say he'd push his autotools
removal branch "in a day or 2 if no issues"... that about 1-2 weeks back. i
didn't see it happen and didn't hear of issues...
are there any? I'd consider merging his branch to remove autofoo at this point.
If meson has issues it should be tested and they should be fixed.
> Andy
>
> On Fri, 17 Nov 2017 at 03:19 Carsten Haitzler wrote:
>
> > raster pushed a commit to branch master.
> >
> >
> > http://git.enlightenment.org/core/enlightenment.git/commit/?id=f4d2d02ba0f15b7f36e7de61141ff88c145f5630
> >
> > commit f4d2d02ba0f15b7f36e7de61141ff88c145f5630
> > Author: Carsten Haitzler (Rasterman)
> > Date: Fri Nov 17 12:17:42 2017 +0900
> >
> > music-control - install properly with meson build with icon
> >
> > @fix
> > ---
> > ...-module-music_control.edj => e-module-music-control.edj} | Bin
> > src/modules/music-control/meson.build | 2 --
> > src/modules/music-control/module.desktop| 2 +-
> > 3 files changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/src/modules/music-control/e-module-music_control.edj
> > b/src/modules/music-control/e-module-music-control.edj
> > similarity index 100%
> > rename from src/modules/music-control/e-module-music_control.edj
> > rename to src/modules/music-control/e-module-music-control.edj
> > diff --git a/src/modules/music-control/meson.build
> > b/src/modules/music-control/meson.build
> > index 996b4196f..a84f5ea8e 100644
> > --- a/src/modules/music-control/meson.build
> > +++ b/src/modules/music-control/meson.build
> > @@ -18,5 +18,3 @@ src += custom_target('gen-dbus',
> > command: [eldbus_codegen, '@INPUT@', '-O', '@OUTDIR@
> > '],
> > output : created_file
> > )
> > -
> > -no_icon = true
> > diff --git a/src/modules/music-control/module.desktop
> > b/src/modules/music-control/module.desktop
> > index 99a2d9143..2e12677e3 100644
> > --- a/src/modules/music-control/module.desktop
> > +++ b/src/modules/music-control/module.desktop
> > @@ -27,5 +27,5 @@ Comment[nl]=Beheers uw muziek op uw plank
> > Comment[ru]=Модуль для управления воспроизведением музыки
> > Comment[sr]=Управљајте музиком са полице
> > Comment[tr]=Müziğinizi rafta kontrol edin
> > -Icon=e-module-music_control
> > +Icon=e-module-music-control
> > X-Enlightenment-ModuleType=utils
> >
> > --
> >
> >
> > --
> http://andywilliams.me
> http://ajwillia.ms
> ------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
- Codito, ergo sum - "I code, therefore I am" --
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] [EGIT] [core/enlightenment] master 01/01: fix mouse hangs after unblank
On Mon, 20 Nov 2017 15:41:09 + Mike Blumenkrantz said: > Thanks for continuing to look into this, fixing this issue alone would > likely be worth pushing out another stable release. The trick was in knowing what caused it. I just never saw it as my mouse just never was over a resize handle (or something that caused the pointer to be changed by E itself). > On Tue, Nov 14, 2017 at 4:16 AM Carsten Haitzler > wrote: > > > raster pushed a commit to branch master. > > > > > > http://git.enlightenment.org/core/enlightenment.git/commit/?id=9fe734318072b4ec86be07d9006f5c36a7556c64 > > > > commit 9fe734318072b4ec86be07d9006f5c36a7556c64 > > Author: Carsten Haitzler (Rasterman) > > Date: Tue Nov 14 18:15:26 2017 +0900 > > > > fix mouse hangs after unblank > > > > this fixes T5883 > > --- > > src/bin/e_comp_x.c | 28 +++- > > src/bin/e_pointer.c | 28 ++-- > > src/bin/e_pointer.h | 4 > > 3 files changed, 41 insertions(+), 19 deletions(-) > > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- 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] [EGIT] [core/enlightenment] master 01/01: music-control - install properly with meson build with icon
On Mon, 20 Nov 2017 15:04:48 + Mike Blumenkrantz
said:
> Issues had been found at an inconvenient time during review, so I left the
> branch unmerged so that someone could either push while I was gone or I
> could push when I returned.
I saw you pushed now. so we know the status. This also clears up the build
system state. I guess I should ensure it's documented. I see README changed but
i am not sure it's correct as it's going to do a build as root... i'll deal
with it. :)
> On Sun, Nov 19, 2017 at 6:56 PM Carsten Haitzler
> wrote:
>
> > On Sun, 19 Nov 2017 13:05:06 + Andrew Williams
> > said:
> >
> > > Hi,
> > >
> > > As the autotool/Makefiles are still in place I fixed the build for users
> > > not yet using the E meson build.
> >
> > i was assuming autotools was dead - mike did say he'd push his autotools
> > removal branch "in a day or 2 if no issues"... that about 1-2 weeks back. i
> > didn't see it happen and didn't hear of issues...
> >
> > are there any? I'd consider merging his branch to remove autofoo at this
> > point.
> > If meson has issues it should be tested and they should be fixed.
> >
> > > Andy
> > >
> > > On Fri, 17 Nov 2017 at 03:19 Carsten Haitzler
> > wrote:
> > >
> > > > raster pushed a commit to branch master.
> > > >
> > > >
> > > >
> > http://git.enlightenment.org/core/enlightenment.git/commit/?id=f4d2d02ba0f15b7f36e7de61141ff88c145f5630
> > > >
> > > > commit f4d2d02ba0f15b7f36e7de61141ff88c145f5630
> > > > Author: Carsten Haitzler (Rasterman)
> > > > Date: Fri Nov 17 12:17:42 2017 +0900
> > > >
> > > > music-control - install properly with meson build with icon
> > > >
> > > > @fix
> > > > ---
> > > > ...-module-music_control.edj => e-module-music-control.edj} | Bin
> > > > src/modules/music-control/meson.build | 2 --
> > > > src/modules/music-control/module.desktop| 2 +-
> > > > 3 files changed, 1 insertion(+), 3 deletions(-)
> > > >
> > > > diff --git a/src/modules/music-control/e-module-music_control.edj
> > > > b/src/modules/music-control/e-module-music-control.edj
> > > > similarity index 100%
> > > > rename from src/modules/music-control/e-module-music_control.edj
> > > > rename to src/modules/music-control/e-module-music-control.edj
> > > > diff --git a/src/modules/music-control/meson.build
> > > > b/src/modules/music-control/meson.build
> > > > index 996b4196f..a84f5ea8e 100644
> > > > --- a/src/modules/music-control/meson.build
> > > > +++ b/src/modules/music-control/meson.build
> > > > @@ -18,5 +18,3 @@ src += custom_target('gen-dbus',
> > > > command: [eldbus_codegen, '@INPUT@', '-O',
> > '@OUTDIR@
> > > > '],
> > > > output : created_file
> > > > )
> > > > -
> > > > -no_icon = true
> > > > diff --git a/src/modules/music-control/module.desktop
> > > > b/src/modules/music-control/module.desktop
> > > > index 99a2d9143..2e12677e3 100644
> > > > --- a/src/modules/music-control/module.desktop
> > > > +++ b/src/modules/music-control/module.desktop
> > > > @@ -27,5 +27,5 @@ Comment[nl]=Beheers uw muziek op uw plank
> > > > Comment[ru]=Модуль для управления воспроизведением музыки
> > > > Comment[sr]=Управљајте музиком са полице
> > > > Comment[tr]=Müziğinizi rafta kontrol edin
> > > > -Icon=e-module-music_control
> > > > +Icon=e-module-music-control
> > > > X-Enlightenment-ModuleType=utils
> > > >
> > > > --
> > > >
> > > >
> > > > --
> > > http://andywilliams.me
> > > http://ajwillia.ms
> > >
> > --
> > > 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] [EGIT] [core/enlightenment] master 01/01: music-control - install properly with meson build with icon
On Tue, 21 Nov 2017 16:37:09 + Mike Blumenkrantz said: > The wording is intentional. The meson build has a tendency to touch build > files during the install phase (which must be run as root to install to the > base system), meaning that failure to use sudo during general build will > fail for subsequent builds anyway due to permissions errors when attempting > to modify root-owned files. i have never had a permission error after a "sudo ninja install" to just run ninja as me to rebuild whatever changed. it's just the gmo files (and install log which obviously is written as root) from gettext... and they are only re-generated by root so ... root overwrites root files. you can delete these files because they are in a directory owned by you (the user). so where is the actual permission problem? a ninja && sudo ninja install will succeed without permission problems (see above). you as a user can delete the effected files too. but suggestion people compile as root is a bad idea. ??? > On Mon, Nov 20, 2017 at 8:14 PM Carsten Haitzler > wrote: > > > On Mon, 20 Nov 2017 15:04:48 + Mike Blumenkrantz > > said: > > > > > Issues had been found at an inconvenient time during review, so I left > > the > > > branch unmerged so that someone could either push while I was gone or I > > > could push when I returned. > > > > I saw you pushed now. so we know the status. This also clears up the build > > system state. I guess I should ensure it's documented. I see README > > changed but > > i am not sure it's correct as it's going to do a build as root... i'll deal > > with it. :) > > > > > On Sun, Nov 19, 2017 at 6:56 PM Carsten Haitzler > > > wrote: > > > > > > > On Sun, 19 Nov 2017 13:05:06 + Andrew Williams < > > a...@andywilliams.me> > > > > said: > > > > > > > > > Hi, > > > > > > > > > > As the autotool/Makefiles are still in place I fixed the build for > > users > > > > > not yet using the E meson build. > > > > > > > > i was assuming autotools was dead - mike did say he'd push his > > autotools > > > > removal branch "in a day or 2 if no issues"... that about 1-2 weeks > > back. i > > > > didn't see it happen and didn't hear of issues... > > > > > > > > are there any? I'd consider merging his branch to remove autofoo at > > this > > > > point. > > > > If meson has issues it should be tested and they should be fixed. > > > > > > > > > Andy > > > > > > > > > > On Fri, 17 Nov 2017 at 03:19 Carsten Haitzler > > > > wrote: > > > > > > > > > > > raster pushed a commit to branch master. > > > > > > > > > > > > > > > > > > > > > > > > http://git.enlightenment.org/core/enlightenment.git/commit/?id=f4d2d02ba0f15b7f36e7de61141ff88c145f5630 > > > > > > > > > > > > commit f4d2d02ba0f15b7f36e7de61141ff88c145f5630 > > > > > > Author: Carsten Haitzler (Rasterman) > > > > > > Date: Fri Nov 17 12:17:42 2017 +0900 > > > > > > > > > > > > music-control - install properly with meson build with icon > > > > > > > > > > > > @fix > > > > > > --- > > > > > > ...-module-music_control.edj => e-module-music-control.edj} | Bin > > > > > > src/modules/music-control/meson.build | 2 > > -- > > > > > > src/modules/music-control/module.desktop| 2 > > +- > > > > > > 3 files changed, 1 insertion(+), 3 deletions(-) > > > > > > > > > > > > diff --git a/src/modules/music-control/e-module-music_control.edj > > > > > > b/src/modules/music-control/e-module-music-control.edj > > > > > > similarity index 100% > > > > > > rename from src/modules/music-control/e-module-music_control.edj > > > > > > rename to src/modules/music-control/e-module-music-control.edj > > > > > > diff --git a/src/modules/music-control/meson.build > > > > > > b/src/modules/music-control/meson.build > > > > > > index 996b4196f..a84f5ea8e 100644 > > > > > > --- a/src/modules/music-control/meson.build > > > > > > +++ b/src/modules/music-control/meson.build >
Re: [E-devel] Eo API docs: Large inheritance content
On Tue, 21 Nov 2017 16:57:18 + Andrew Williams said: > Hi team, > > Looking at some of our larger inheritance trees, such as > https://www.enlightenment.org/develop/api/class/efl/ui/clock , may provide > only 8 members but the page runs to hundreds of items - a complete bed time > read in itself. I think for the sanity of our readers it would be good to > list the members it inherits in short hand. Like the somewhat standardised > JavaDoc output - > https://docs.oracle.com/javase/7/docs/api/java/io/OutputStreamWriter.html > > Additionally the complete heirarchy tree at the top of each page takes a > lot of space and repeats a lot - it would make sense to flatten this to a > list. I like the tree at the top... It does contain very useful information of where the class comes from in the scheme of things. Why not use a foldable section? Expand it if you want the tree, otherwise stay collapsed? Same for all of the inherited methods/properties etc. - put them all in foldable sections you expand? > Are there any objections to these changes? > > Thanks, > Andy > -- > http://andywilliams.me > http://ajwillia.ms > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- 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] SPDX header
On Tue, 21 Nov 2017 13:36:08 -0500 Cedric Bail said: > Hi, > > If you have followed the kernel development, you may have seen that they are > prefixxing all there source code file with a SPDX comment like : > > /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ > > This headers help automated tool to figure out the licenses of a specific > file and allow companies to properly act on this information. EFL has a lot > of different licenses and it would be a very good idea to actually roll that > in. Is anyone opposed to this being rolled in during the next few weeks ? are you going to automate it based on the licensing info we already have (just run a script over a tree or subtree)? can you leave src/lib/ecore/* alone for now? do this later... -- - Codito, ergo sum - "I code, therefore I am" -- 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] [EGIT] [core/efl] master 01/01: ecore: reformat ecore_exe_posix.c
On Tue, 21 Nov 2017 09:31:38 -0800 Mike Blumenkrantz said: Just a request... can you not do "reformatting" of anything in ecore (src/lib/ecore) right now. I am actually in the middle of ACTUALLY making the main loop a real object (moving fd handlers, win32 handlers, timers, event queue etc.) actually our of global variables into the actual loop object to pave the way for actual multiple loop objects. it's proving problematic as i'm discovering all the nasties like provider_find failing during construction and destruction (thanks to losing parent) etc. and this has also meant rejigging chunks of code and cleaning up a decade or 2 of "mess" just to see the forest from the trees. It'll make my life easier with fewer or smaller conflicts. :) > discomfitor pushed a commit to branch master. > > http://git.enlightenment.org/core/efl.git/commit/?id=7cdbe6e029be7fe5db0d12b8af1e17101692943f > > commit 7cdbe6e029be7fe5db0d12b8af1e17101692943f > Author: Mike Blumenkrantz > Date: Tue Nov 21 12:24:51 2017 -0500 > > ecore: reformat ecore_exe_posix.c > --- > src/lib/ecore/ecore_exe_posix.c | 1413 +++ > +--- 1 file changed, 708 insertions(+), 705 deletions(-) > > diff --git a/src/lib/ecore/ecore_exe_posix.c b/src/lib/ecore/ecore_exe_posix.c > index 3cbba20f44..bebfce26a1 100644 > --- a/src/lib/ecore/ecore_exe_posix.c > +++ b/src/lib/ecore/ecore_exe_posix.c > @@ -49,52 +49,54 @@ struct _ecore_exe_dead_exe > char *cmd; > }; > > -static inline void _ecore_exe_exec_it(const char *exe_cmd, > +static inline void _ecore_exe_exec_it(const char *exe_cmd, >Ecore_Exe_Flags flags); > -static Eina_Bool _ecore_exe_data_generic_handler(void *data, > +static Eina_Bool _ecore_exe_data_generic_handler(void *data, > Ecore_Fd_Handler > *fd_handler, > - Ecore_Exe_Flags flags); > -static Eina_Bool_ecore_exe_data_error_handler(void > *data, > - Ecore_Fd_Handler > *fd_handler); -static Eina_Bool_ecore_exe_data_read_handler > (void *data, > - Ecore_Fd_Handler > *fd_handler); -static Eina_Bool_ecore_exe_data_write_handler > (void *data, > - Ecore_Fd_Handler > *fd_handler); -static void _ecore_exe_flush(Ecore_Exe *obj); > -static Ecore_Exe *_ecore_exe_is_it_alive(pid_t pid); > -static Eina_Bool_ecore_exe_make_sure_its_dead(void *data); > -static Eina_Bool_ecore_exe_make_sure_its_really_dead(void *data); > -static void _ecore_exe_dead_attach(Ecore_Exe *obj); > + Ecore_Exe_Flags flags); > +static Eina_Bool _ecore_exe_data_error_handler(void *data, > + Ecore_Fd_Handler > *fd_handler); +static Eina_Bool _ecore_exe_data_read_handler(void *data, > +Ecore_Fd_Handler > *fd_handler); +static Eina_Bool _ecore_exe_data_write_handler(void *data, > + Ecore_Fd_Handler > *fd_handler); +static void_ecore_exe_flush(Ecore_Exe *obj); > +static Ecore_Exe *_ecore_exe_is_it_alive(pid_t pid); > +static Eina_Bool _ecore_exe_make_sure_its_dead(void *data); > +static Eina_Bool _ecore_exe_make_sure_its_really_dead(void *data); > +static void_ecore_exe_dead_attach(Ecore_Exe *obj); > > static const char *shell = NULL; > > /* FIXME: This errno checking stuff should be put elsewhere for everybody to > use. > * For now it lives here though, just to make testing easier. > */ > -static int _ecore_exe_check_errno(int result, > - const char *file, > - int line); > +static int _ecore_exe_check_errno(int result, > + const char *file, > + int line); > > -#define E_IF_NO_ERRNO(result, foo, > ok) \ > - while (((ok) = _ecore_exe_check_errno((result) = (foo), __FILE__, > __LINE__)) == -1) sleep(1); \ > - if (ok) > +#define E_IF_NO_ERRNO(result, foo, > ok)\ > + while (((ok) = _ecore_exe_check_errno((result) = (foo), __FILE__, > __LINE__)) == -1) \ > +sleep > (1); \ > + if (ok) > > -#define E_NO_ERRNO(result, foo, ok) \ > - while (((ok) = _ecore_exe_check_errno((result) = (foo), __FILE__, > __LINE__)) == -1) sleep(1) +#define E_NO_ERRNO(result, foo, > ok)
Re: [E-devel] Website Table of Contents
On Mon, 20 Nov 2017 12:18:09 + Andrew Williams said: > Hi, > > So I've tried to get a ToC appended to the nav sidebar and I'm not > disappointed with the result. > https://www.enlightenment.org/ss/display.php?image=e-5a12a60dc3d772.36151853.jpg > > If there is space the bar is static on the top right of the screen, if > there is not a wide enough gutter then it inlines at the top right of the > content. It seems this is broken (overlaps a lot of content - just by luck the content doesn't have long enough lines there to be hidden): https://www.enlightenment.org/develop/api/class/efl/object http://www.enlightenment.org/ss/e-5a14c363eec9d0.43575629.png It shouldn't "gutter" IMHO in this case either like on mobile like displays. I think you need a better solution. Most of that ToC IMHO is not useful while reading reference docs. Especially the Tutorials, Setup and APIs. Tutorials there is hopefully going to expand to 100's of items making this pretty pointless. The Page Contents is the useful part as a "jump to this section". I assume for now most of that is "sample content" and will be reconsidered in future? I am thinking this should really just be a dropdown menu like Options etc. perhaps displayed by default? At least so I can hide it and read the content underneath? > It appears when there are 3 or more headings at level 2 and 3 - that means > we ignore top level headings (usually a page title) and expand 1 level if > the current top level area has child elements. Most of this is the ToC > plugin in dokuwiki and works quite well. > > Comments welcome, plenty of opportunity to adapt it to suit our style. > Andy > > On Wed, 8 Nov 2017 at 07:27 Carsten Haitzler wrote: > > > On Tue, 07 Nov 2017 15:59:24 + Andrew Williams > > said: > > > > > Hi, > > > > > > The amount of space it takes up is a stylistic issue - our template > > > explicitly reserves 1/4 of the screen for a ToC which is clearly not a > > > requirement. > > > > that was my major thing about it. stylistic. :) also the original css for > > it > > was a bit blergh and i didn't feel like fixing it up to be nicer so > > removing was > > less work. that's why i didnt do the TOC though. if you're going to do > > one... > > do it well. :) > > > > > Additionally of concern is that many of our pages (specifically the > > program > > > guide) have (manually entered) contents areas that are within the page > > > content. > > > https://www.enlightenment.org/develop/legacy/program_guide/eina/arrays > > > > That's kind of odd... I'd just remove it IMHO... :) > > > > > As part of this documentation effort we are seeing navigation as an area > > in > > > which we are significantly lacking so I think we can spend some time > > fixing > > > it. > > > I am a little unsure as to whether the main objection here is that we see > > > ToC as a bad thing or if we just did not find a way to include it neatly > > in > > > our layout. > > > > a little of the first but mostly the second. if you need a TOC because the > > page > > is so big ... i kind of think it should be split up... :) > > > > > If it were possible to make it well presented would people be generally > > in > > > favour of moving the ToCs into a standard (sidebar?) area so, where pages > > > need it, we can have the contents presented in a standard form (whilst > > > being auto generated)? > > > > see the first above :) > > > > > Thanks, > > > Andrew > > > > > > On Tue, 7 Nov 2017 at 12:51 Carsten Haitzler > > wrote: > > > > > > > On Mon, 06 Nov 2017 18:47:45 + Andrew Williams < > > a...@andywilliams.me> > > > > said: > > > > > > > > > Hi, > > > > > > > > > > With some of the examples in our new documentation there is a lot of > > > > > content and there was a request to generate a table of contents. > > > > > This feature has been turned off on our wiki and I wondered how > > people > > > > > would feel about us turning this back on. With the current styling it > > > > looks > > > > > like this screenshot: > > > > > https://www.enlightenment.org/ss/e-5a00adba813593.05237914.jpg > > > > > > > > Hmmm... My take is that I don't like it. Dokuwiki by default had a TOC > > and > > > > I > > > > actually turned it off it. I
[E-devel] ecore main loop -> efl_loop full convert
So we had a partly done move to efl_loop. it still was all built on top of the main loop globals. If this is all done right then we can have multiple loops (e.g. one per thread) and that is a good thing. So I've been fixing that. I've done just about all the globals in ecore EXCEPT ecore events. I now have to think about how to do this in eo/interfaces with efl loop objects and so on. I'm mulling how to do it. We still have some need for a deferred event bus/queue. A lot of things that are ecore events should be callbacks on objects directly and that's being fixed, but an event queue + types is still needed. So there are a few aspects to this. 1. Creating of new event types at runtime (and allocating a unique identifier for them). 2. Being able to submit them to a queue to be "processed later" 3. Being able to call callbacks that are listening for that type of event and hand them the deferred event data. This is used as the backing for ecore_jobs and pretty much every i/o thing (input events, i/o and more) as well as in-process custom event bus+events. My current thought is this. 1. event types are still ints with a single global shared backing table of all event types (allocated once ever much like atoms in x). 2. event event is an eo object on the queue (of some type). 3. some event object "factory" on the loop that creates and "deletes" (caches then) these event objects for recycling. Does anyone have better ideas? I considered the event type being an object itself and also doubling as a factory per event type but due to multiple threads you'd probably be creating an object then per thread per event type and I do not like that. -- - Codito, ergo sum - "I code, therefore I am" -- 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] [EGIT] [core/enlightenment] master 01/01: music-control - install properly with meson build with icon
On Wed, 22 Nov 2017 10:33:05 +0100 Jérémy Zurcher said: > Hi, > > I confirm, I had to add the above in my build script : > > sudo -S chown $USER $BUILD_DIR/.ninja_deps $BUILD_DIR/.ninja_log 7:14PM ~/C/e/build ⎇ master > ls -al total 4.4M 4.0K drwxr-xr-x 9 raster raster 4.0K Nov 22 15:36 ./ 4.0K drwxr-xr-x 10 raster raster 4.0K Nov 22 15:36 ../ 1.6M -rw-r--r-- 1 raster raster 1.6M Nov 22 15:36 .ninja_deps 64K -rw-r--r-- 1 raster raster 61K Nov 22 15:36 .ninja_log written not as root. (make ninja install was as root). ... ? > On Wednesday 22 November 2017 08:18, Andrew Williams wrote : > > Hi, > > > > Compiling as root may be a bad thing but mike is right, ninja install hits > > log files and other - some times causing root ownership. I have seen it > > occasionally myself and have had to either delete the build tree or chown > > it to myself. > > > > Perhaps this is a bug we should be reporting but in the meantime our docs > > should cover it somehow. > > > > Andy > > On Wed, 22 Nov 2017 at 00:19, Carsten Haitzler wrote: > > > > > On Tue, 21 Nov 2017 16:37:09 + Mike Blumenkrantz > > > said: > > > > > > > The wording is intentional. The meson build has a tendency to touch > > > > build files during the install phase (which must be run as root to > > > > install to > > > the > > > > base system), meaning that failure to use sudo during general build will > > > > fail for subsequent builds anyway due to permissions errors when > > > attempting > > > > to modify root-owned files. > > > > > > i have never had a permission error after a "sudo ninja install" to just > > > run > > > ninja as me to rebuild whatever changed. it's just the gmo files (and > > > install > > > log which obviously is written as root) from gettext... and they are only > > > re-generated by root so ... root overwrites root files. you can delete > > > these > > > files because they are in a directory owned by you (the user). > > > > > > so where is the actual permission problem? a ninja && sudo ninja install > > > will > > > succeed without permission problems (see above). you as a user can delete > > > the > > > effected files too. > > > > > > but suggestion people compile as root is a bad idea. > > > > > > ??? > > > > > > > On Mon, Nov 20, 2017 at 8:14 PM Carsten Haitzler > > > > wrote: > > > > > > > > > On Mon, 20 Nov 2017 15:04:48 + Mike Blumenkrantz > > > > > said: > > > > > > > > > > > Issues had been found at an inconvenient time during review, so I > > > left > > > > > the > > > > > > branch unmerged so that someone could either push while I was gone > > > or I > > > > > > could push when I returned. > > > > > > > > > > I saw you pushed now. so we know the status. This also clears up the > > > build > > > > > system state. I guess I should ensure it's documented. I see README > > > > > changed but > > > > > i am not sure it's correct as it's going to do a build as root... i'll > > > deal > > > > > with it. :) > > > > > > > > > > > On Sun, Nov 19, 2017 at 6:56 PM Carsten Haitzler < > > > ras...@rasterman.com> > > > > > > wrote: > > > > > > > > > > > > > On Sun, 19 Nov 2017 13:05:06 + Andrew Williams < > > > > > a...@andywilliams.me> > > > > > > > said: > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > As the autotool/Makefiles are still in place I fixed the build > > > for > > > > > users > > > > > > > > not yet using the E meson build. > > > > > > > > > > > > > > i was assuming autotools was dead - mike did say he'd push his > > > > > autotools > > > > > > > removal branch "in a day or 2 if no issues"... that about 1-2 > > > > > > > weeks > > > > > back. i > > > > > > > didn't see it happen and didn't hear of issues... > > > > > > > > > > > > > > are there any? I'd consider merging his br
Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: music-control - install properly with meson build with icon
On Wed, 22 Nov 2017 08:18:54 + Andrew Williams said: > Hi, > > Compiling as root may be a bad thing but mike is right, ninja install hits > log files and other - some times causing root ownership. I have seen it > occasionally myself and have had to either delete the build tree or chown > it to myself. > > Perhaps this is a bug we should be reporting but in the meantime our docs > should cover it somehow. It's not "on occasion" that they are written to. they are ALWAYS written to. the *.gmo files in po/ and the install log. as the owner of the parent dir, the user is allowed to delete these so it shouldn't be a problem. but suggestion people compile as root is a pretty bad idea. compiling as user then installing as root i don't see how it can create problems. the same files (installlog and gmo files) are ONLY overwritten again when you do a make install - as root with sudo. unless you are installing as a user to a destdir or something ... then you may have issues. > Andy > On Wed, 22 Nov 2017 at 00:19, Carsten Haitzler wrote: > > > On Tue, 21 Nov 2017 16:37:09 + Mike Blumenkrantz > > said: > > > > > The wording is intentional. The meson build has a tendency to touch build > > > files during the install phase (which must be run as root to install to > > the > > > base system), meaning that failure to use sudo during general build will > > > fail for subsequent builds anyway due to permissions errors when > > attempting > > > to modify root-owned files. > > > > i have never had a permission error after a "sudo ninja install" to just > > run > > ninja as me to rebuild whatever changed. it's just the gmo files (and > > install > > log which obviously is written as root) from gettext... and they are only > > re-generated by root so ... root overwrites root files. you can delete > > these > > files because they are in a directory owned by you (the user). > > > > so where is the actual permission problem? a ninja && sudo ninja install > > will > > succeed without permission problems (see above). you as a user can delete > > the > > effected files too. > > > > but suggestion people compile as root is a bad idea. > > > > ??? > > > > > On Mon, Nov 20, 2017 at 8:14 PM Carsten Haitzler > > > wrote: > > > > > > > On Mon, 20 Nov 2017 15:04:48 + Mike Blumenkrantz > > > > said: > > > > > > > > > Issues had been found at an inconvenient time during review, so I > > left > > > > the > > > > > branch unmerged so that someone could either push while I was gone > > or I > > > > > could push when I returned. > > > > > > > > I saw you pushed now. so we know the status. This also clears up the > > build > > > > system state. I guess I should ensure it's documented. I see README > > > > changed but > > > > i am not sure it's correct as it's going to do a build as root... i'll > > deal > > > > with it. :) > > > > > > > > > On Sun, Nov 19, 2017 at 6:56 PM Carsten Haitzler < > > ras...@rasterman.com> > > > > > wrote: > > > > > > > > > > > On Sun, 19 Nov 2017 13:05:06 + Andrew Williams < > > > > a...@andywilliams.me> > > > > > > said: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > As the autotool/Makefiles are still in place I fixed the build > > for > > > > users > > > > > > > not yet using the E meson build. > > > > > > > > > > > > i was assuming autotools was dead - mike did say he'd push his > > > > autotools > > > > > > removal branch "in a day or 2 if no issues"... that about 1-2 weeks > > > > back. i > > > > > > didn't see it happen and didn't hear of issues... > > > > > > > > > > > > are there any? I'd consider merging his branch to remove autofoo at > > > > this > > > > > > point. > > > > > > If meson has issues it should be tested and they should be fixed. > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > On Fri, 17 Nov 2017 at 03:19 Carsten Haitzler < > > ras...@rasterman.com> > > > > > > wrote: > > > > &
Re: [E-devel] Git Feature/ Proposal
On Wed, 22 Nov 2017 08:12:13 + Andrew Williams said: > Can we instead ask people to pull master into their branch before asking > for review / merging it up to master? That’s pretty common practice - in > fact for a long lived branch I would expect that to happen on a regular > basis. That would be at a minimum. > Andy > On Wed, 22 Nov 2017 at 02:56, Jean-Philippe André wrote: > > > My problem is that those branches won't be in sync with master. > > This will lead to merge conflicts. I am these days reviewing a lot of work > > done in dev branches or phab patches and it almost never applies nicely on > > master, because the interfaces change. > > A lot of work is done in branches (model, c#, eo widgets, ...) and those > > tasks are both long term and involve more than a single dev. They require > > constant rebasing on master or the final rebase will be a nightmare. Right > > now this is done by people pulling other devs branches, and then rebasing > > onto master in their own dev branch. > > > > Rewriting history on a shared branch has major downsides too. No problem > > for dev branches as there's only one committer, but anyone pulling a > > rewritten history will endure pain. > > > > Honestly I don't have a solution. > > > > It's a move in the right direction, but I'm not sure it's solving the > > problems I'm facing :( > > > > > > > > 2017-11-22 3:43 GMT+09:00 Tom Hacohen : > > > > > Only problem would be the commit emails being resent (because > > > technically they are new commits). One can mitigate that by first > > > pushing them to a dev branch. Commits there have first been there > > > don't trigger emails. > > > > > > On Tue, Nov 21, 2017 at 6:40 PM, Mike Blumenkrantz > > > wrote: > > > > In the issue where a significant rebase against master is necessary > > then > > > > it's trivial enough to either push to a new feature branch or delete > > and > > > > re-create the existing branch. > > > > > > > > On Tue, Nov 21, 2017 at 1:36 PM Tom Hacohen wrote: > > > > > > > >> As Mike said, the rebase/sync to master is being done locally before > > > >> the merge. If you are talking about keeping this branch in sync with > > > >> master constantly while developing, yes it's a problem. But I guess > > > >> it's not intended for long term features. > > > >> > > > >> On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz > > > >> wrote: > > > >> > I don't see a difference in the merge process? A feature branch > > > should be > > > >> > treated exactly the same as master; the only difference is that > > it's a > > > >> > branch which people must specifically pull in order to use instead > > of > > > >> being > > > >> > master. > > > >> > > > > >> > When merging, you can either do a regular rebase/merge as in the git > > > >> > practices documentation or you can choose to rebase/squash on the > > > >> branched > > > >> > commits prior to pushing the merge. There is no rewriting within the > > > >> > branch, but you can still rewrite anything which has not been pushed > > > to > > > >> > master just prior to pushing it to master. > > > >> > > > > >> > On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André < > > > j...@videolan.org> > > > >> > wrote: > > > >> > > > > >> >> Hey, > > > >> >> > > > >> >> If we can't rewrite history on those branches (rebase and push -f), > > > how > > > >> >> should we proceed with the merge to/from master? > > > >> >> Usually when we merge a branch to master, we rebase it on top of > > > master > > > >> >> first and then rebase. That's how our history remains linear and > > > simple. > > > >> >> > > > >> >> What's the idea here? I wonder. > > > >> >> > > > >> >> Thanks for implementing this btw, > > > >> >> > > > >> >> 2017-11-21 8:49 GMT+09:00 Tom Hacohen : > > > >> >> > > > >> >> > I'm not sure about jenkins, that's Stefan's role. &g
Re: [E-devel] Website Table of Contents
On Wed, 22 Nov 2017 10:29:29 + Andrew Williams said: > Hi, > > If you are seeing broken rendering please refresh the cache - there are CSS > changes in there that will need to be grabbed as well as the content. shift-reloaded. same story. overlaps. :) > In your screenshot I don't know what you mean by "gutter" - the screen is > not wide enough for it to have moved into the gutter, which it will do when > possible to make the most of the fixed-width content. between the top menu bar and content of screen thus pushing all the content down by the size of the nav ToC. > The sidebar is split into 2 - at the top is a navigation for that namespace > (can change per-namespace) and the Page Contents is generated based on the > headings within a page. As you say the content here can change and this is > just to get things rolling. The main objection to ToC was that it could not > look good, so I am trying to make that work after which the content could > be finalised. The tutorials indeed could be collapsed - but we wanted to > have enough content in here to make it meaningful to discuss. Well It probably would be good to collapse this as it is overlapping content ... or specifically allow it to collapse to get it out of the way when someone needs that content. > I don't know what you mean about "content underneath" - this does not cover > any content, it displaces it. And on a wider window it does not even > displace any content. We are trying to avoid dropdowns as much as possible, > as discussed in another thread they are not very discoverable etc. It overlaps the the divs with the function prototypes in them. the divs are going under the ToC. you can see at the bottom of the. > One main aim of this is to get some consistency and flow over the site. > Many, many of our pages have built in ToC or Navigation to work around the > fact that we have none so making a standard space where this is presented > should help a lot for those struggling to find the right documentation. I never really thought that was a good idea. Someone decided to add it in by hand. it should not have been added by hand at all. It is duplicating what can be automated. Then the only question is if it should be there at all. But Having it collapse would be good to get it out of the way when not needed or wanted. ALLOW it to collapse. Expand it by default. All that is is then a "collapse/expand" arrow/button at the bottom of the ToC to do this. > Thanks, > Andy > > On Wed, 22 Nov 2017 at 00:29 Carsten Haitzler wrote: > > > On Mon, 20 Nov 2017 12:18:09 + Andrew Williams > > said: > > > > > Hi, > > > > > > So I've tried to get a ToC appended to the nav sidebar and I'm not > > > disappointed with the result. > > > > > https://www.enlightenment.org/ss/display.php?image=e-5a12a60dc3d772.36151853.jpg > > > > > > If there is space the bar is static on the top right of the screen, if > > > there is not a wide enough gutter then it inlines at the top right of the > > > content. > > > > It seems this is broken (overlaps a lot of content - just by luck the > > content > > doesn't have long enough lines there to be hidden): > > > > https://www.enlightenment.org/develop/api/class/efl/object > > > > http://www.enlightenment.org/ss/e-5a14c363eec9d0.43575629.png > > > > It shouldn't "gutter" IMHO in this case either like on mobile like > > displays. I > > think you need a better solution. Most of that ToC IMHO is not useful while > > reading reference docs. Especially the Tutorials, Setup and APIs. Tutorials > > there is hopefully going to expand to 100's of items making this pretty > > pointless. The Page Contents is the useful part as a "jump to this > > section". I > > assume for now most of that is "sample content" and will be reconsidered in > > future? > > > > I am thinking this should really just be a dropdown menu like Options etc. > > perhaps displayed by default? At least so I can hide it and read the > > content > > underneath? > > > > > It appears when there are 3 or more headings at level 2 and 3 - that > > means > > > we ignore top level headings (usually a page title) and expand 1 level if > > > the current top level area has child elements. Most of this is the ToC > > > plugin in dokuwiki and works quite well. > > > > > > Comments welcome, plenty of opportunity to adapt it to suit our style. > > > Andy > > > > > > On Wed, 8 Nov 2017 at 07:27 Carsten Haitzler > > wrote: > > > > > > >
Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: music-control - install properly with meson build with icon
On Wed, 22 Nov 2017 10:36:36 + Andrew Williams said: > Hi, > > I'm glad that it is not affecting you. Jeyzu and I both seem to have hit > this issue (and I guess zmike too as described earlier). > Some times after a "sudo ninja install" I can no longer "ninja" due to > permissions issues with files that have become root owned. > > It is unfortunate but it would be good to get a solution that works all the > time for everyone if possible. I checked what files were root owned. I currently don't see a reason why it should fail. Someone show me a reason where it does fail (a file written to as root has to be overwritten as a user or it cannot be deleted as a user). I don't see it. perhaps its a bug in meson in an older version? or a newer one? > Andy > > On Wed, 22 Nov 2017 at 10:17 Carsten Haitzler wrote: > > > On Wed, 22 Nov 2017 10:33:05 +0100 Jérémy Zurcher said: > > > > > Hi, > > > > > > I confirm, I had to add the above in my build script : > > > > > > sudo -S chown $USER $BUILD_DIR/.ninja_deps $BUILD_DIR/.ninja_log > > > > 7:14PM ~/C/e/build ⎇ master > ls -al > > total 4.4M > > 4.0K drwxr-xr-x 9 raster raster 4.0K Nov 22 15:36 ./ > > 4.0K drwxr-xr-x 10 raster raster 4.0K Nov 22 15:36 ../ > > 1.6M -rw-r--r-- 1 raster raster 1.6M Nov 22 15:36 .ninja_deps > > 64K -rw-r--r-- 1 raster raster 61K Nov 22 15:36 .ninja_log > > > > written not as root. (make ninja install was as root). ... ? > > > > > On Wednesday 22 November 2017 08:18, Andrew Williams wrote : > > > > Hi, > > > > > > > > Compiling as root may be a bad thing but mike is right, ninja install > > hits > > > > log files and other - some times causing root ownership. I have seen it > > > > occasionally myself and have had to either delete the build tree or > > chown > > > > it to myself. > > > > > > > > Perhaps this is a bug we should be reporting but in the meantime our > > docs > > > > should cover it somehow. > > > > > > > > Andy > > > > On Wed, 22 Nov 2017 at 00:19, Carsten Haitzler > > wrote: > > > > > > > > > On Tue, 21 Nov 2017 16:37:09 + Mike Blumenkrantz > > > > > said: > > > > > > > > > > > The wording is intentional. The meson build has a tendency to touch > > > > > > build files during the install phase (which must be run as root to > > > > > > install to > > > > > the > > > > > > base system), meaning that failure to use sudo during general > > build will > > > > > > fail for subsequent builds anyway due to permissions errors when > > > > > attempting > > > > > > to modify root-owned files. > > > > > > > > > > i have never had a permission error after a "sudo ninja install" to > > just > > > > > run > > > > > ninja as me to rebuild whatever changed. it's just the gmo files (and > > > > > install > > > > > log which obviously is written as root) from gettext... and they are > > only > > > > > re-generated by root so ... root overwrites root files. you can > > delete > > > > > these > > > > > files because they are in a directory owned by you (the user). > > > > > > > > > > so where is the actual permission problem? a ninja && sudo ninja > > install > > > > > will > > > > > succeed without permission problems (see above). you as a user can > > delete > > > > > the > > > > > effected files too. > > > > > > > > > > but suggestion people compile as root is a bad idea. > > > > > > > > > > ??? > > > > > > > > > > > On Mon, Nov 20, 2017 at 8:14 PM Carsten Haitzler < > > ras...@rasterman.com> > > > > > > wrote: > > > > > > > > > > > > > On Mon, 20 Nov 2017 15:04:48 + Mike Blumenkrantz > > > > > > > said: > > > > > > > > > > > > > > > Issues had been found at an inconvenient time during review, > > so I > > > > > left > > > > > > > the > > > > > > > > branch unmerged so that someone could either push while I was > > gone > > > > > or I > > > > > > >
Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: music-control - install properly with meson build with icon
On Wed, 22 Nov 2017 20:13:48 + Mike Blumenkrantz said: > I'm on fedora with meson 0.42.1 and ninja 1.8.2 Can you try doing the "build as user, install as root/sudo" and hit the issue and details exactly what files are owned by root at that point and what file the problem is with and why the permission problem is there? I just can't see the source of the issue in my build trees. > On Wed, Nov 22, 2017 at 1:08 PM Andrew Williams > wrote: > > > Hi, > > > > I'm on Arch and generally try to stay up to date so maybe they have fixed > > it? > > Mike? > > > > On Wed, 22 Nov 2017 at 15:55 Jérémy Zurcher wrote: > > > > > I can't reproduce that root owner ship issue right now. > > > I made the changes to my scripts on the 2017/08/17 > > > at that time on my archlinux boxes ninja was 1.7.2 and meson was 0.41.2 > > > since then ninja has been upgraded to 1.8.2, and meson to 0.42.1 then > > > 0.43.0 > > > maybe it has been fixed in one of them fixed now. > > > (but I won't dive into their respective repos to check that ;) > > > > > > > > > On Wednesday 22 November 2017 20:51, Carsten Haitzler wrote : > > > > On Wed, 22 Nov 2017 10:36:36 + Andrew Williams < > > a...@andywilliams.me> > > > said: > > > > > > > > > Hi, > > > > > > > > > > I'm glad that it is not affecting you. Jeyzu and I both seem to have > > > hit > > > > > this issue (and I guess zmike too as described earlier). > > > > > Some times after a "sudo ninja install" I can no longer "ninja" due > > to > > > > > permissions issues with files that have become root owned. > > > > > > > > > > It is unfortunate but it would be good to get a solution that works > > > all the > > > > > time for everyone if possible. > > > > > > > > I checked what files were root owned. I currently don't see a reason > > why > > > it > > > > should fail. Someone show me a reason where it does fail (a file > > written > > > to as > > > > root has to be overwritten as a user or it cannot be deleted as a > > user). > > > I > > > > don't see it. perhaps its a bug in meson in an older version? or a > > newer > > > one? > > > > > > > > > Andy > > > > > > > > > > On Wed, 22 Nov 2017 at 10:17 Carsten Haitzler > > > wrote: > > > > > > > > > > > On Wed, 22 Nov 2017 10:33:05 +0100 Jérémy Zurcher > > > > > said: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I confirm, I had to add the above in my build script : > > > > > > > > > > > > > > sudo -S chown $USER $BUILD_DIR/.ninja_deps $BUILD_DIR/.ninja_log > > > > > > > > > > > > 7:14PM ~/C/e/build ⎇ master > ls -al > > > > > > total 4.4M > > > > > > 4.0K drwxr-xr-x 9 raster raster 4.0K Nov 22 15:36 ./ > > > > > > 4.0K drwxr-xr-x 10 raster raster 4.0K Nov 22 15:36 ../ > > > > > > 1.6M -rw-r--r-- 1 raster raster 1.6M Nov 22 15:36 .ninja_deps > > > > > > 64K -rw-r--r-- 1 raster raster 61K Nov 22 15:36 .ninja_log > > > > > > > > > > > > written not as root. (make ninja install was as root). ... ? > > > > > > > > > > > > > On Wednesday 22 November 2017 08:18, Andrew Williams wrote : > > > > > > > > Hi, > > > > > > > > > > > > > > > > Compiling as root may be a bad thing but mike is right, ninja > > > install > > > > > > hits > > > > > > > > log files and other - some times causing root ownership. I have > > > seen it > > > > > > > > occasionally myself and have had to either delete the build > > tree > > > or > > > > > > chown > > > > > > > > it to myself. > > > > > > > > > > > > > > > > Perhaps this is a bug we should be reporting but in the > > meantime > > > our > > > > > > docs > > > > > > > > should cover it somehow. > > > > > > > > > > > > > > > > And
Re: [E-devel] ecore main loop -> efl_loop full convert
schedule, ctx); // future
> chain that auto re-schedules and calls user
>ctx->future = future2;
>
>
> // efl_loop_receiver_del()
> foreach ctx of loop->receivers { // or loop->receivers[event_class]
> if (ctx->event_class == event_class && ctx->cb == cb && ctx->data
> == data) {
> efl_future_cancel(ctx->future);
> loop->receivers.remove(ctx);
> free(ctx);
> return true;
> }
> }
> return false; // not found
>
>
> Advantages:
>
> - very simple to implement, basically invert Promise/Future <->
> Ecore_Event handling in existing main loop;
>
> - Job is natively handled (since it's a promise/future in the new api);
>
> - single shot events are the core, very easy to manage
>
> - recurring events are done on top of single shot, adds one more cb,
> but no big deal in performance (if it's, just reverse the structures)
>
> - events as proper Eo objects: give us many possibilities without
> need to implement extras, like references, methods (getters, protected
> setters)...
>
> I'd not go with Eina_Value as events. It could be done, would work
> exactly the same but offers less flexibility (needs copy intead of ref
> count, no way to protect members). But if Eo is considered too heavy
> or cumbersome, it could be used. (cumbersome: remember eolian should
> help!)
>
> For Eina_Value_Type, special care would be needed for structures...
> I'm not expecting users to create new Eina_Value_Type for each event,
> rather just use EINA_VALUE_TYPE_STRUCT or similar. In these cases,
> "subtype" is needed, that describes the structure itself (it can be
> used as event_class). Or impose it's always a structure and in this
> case pass the Eina_Value_Struct_Desc instead of Eina_Value_Type as
> "event_class".
eina value might be another option for the event object to be posted, but i
kind of leaned to the heavier eo objects... because i know it's what we do for
input events already and it can be optimized as above to be less costly.
> On Wed, Nov 22, 2017 at 5:38 AM, Jean-Philippe André
> wrote:
> > Hi,
> >
> > I talked to raster for clarification.
> >
> > 2017-11-22 14:57 GMT+09:00 Carsten Haitzler :
> >
> >> So we had a partly done move to efl_loop. it still was all built on top of
> >> the
> >> main loop globals. If this is all done right then we can have multiple
> >> loops
> >> (e.g. one per thread) and that is a good thing.
> >>
> >> So I've been fixing that. I've done just about all the globals in ecore
> >> EXCEPT
> >> ecore events. I now have to think about how to do this in eo/interfaces
> >> with
> >> efl loop objects and so on. I'm mulling how to do it.
> >>
> >> We still have some need for a deferred event bus/queue. A lot of things
> >> that
> >> are ecore events should be callbacks on objects directly and that's being
> >> fixed, but an event queue + types is still needed.
> >>
> >> So there are a few aspects to this.
> >>
> >> 1. Creating of new event types at runtime (and allocating a unique
> >> identifier
> >> for them).
> >> 2. Being able to submit them to a queue to be "processed later"
> >> 3. Being able to call callbacks that are listening for that type of event
> >> and
> >> hand them the deferred event data.
> >>
> >> This is used as the backing for ecore_jobs and pretty much every i/o thing
> >> (input events, i/o and more) as well as in-process custom event bus+events.
> >>
> >> My current thought is this.
> >>
> >> 1. event types are still ints with a single global shared backing table of
> >> all
> >> event types (allocated once ever much like atoms in x).
> >> 2. event event is an eo object on the queue (of some type).
> >> 3. some event object "factory" on the loop that creates and "deletes"
> >> (caches
> >> then) these event objects for recycling.
> >>
> >> Does anyone have better ideas? I considered the event type being an object
> >> itself and also doubling as a factory per event type but due to multiple
> >> threads you'd probably be creating an object then per thread per event
> >> type and
> >> I do not like that.
> >
> >
> >
> > Basically we have two base EO types:
> >
> > - "ecore event type" EO class:
> > singleton per loop, it's a handle
>
Re: [E-devel] ecore main loop -> efl_loop full convert
On Sat, 25 Nov 2017 20:59:08 -0200 Gustavo Sverzut Barbieri said: > On Thu, Nov 23, 2017 at 10:42 PM, Carsten Haitzler > wrote: [...] > >> - broadcast events: use Eo as below: > >> > >>* no "event type", just event object (which as its Efl_Class, of > >> course); > > > > that was the idea. you allocate a new event type (get an int or handle). you > > then GET the event type object from the loop, then listen to "event" > > callback on it. same one on every event type object. the object > > "represents" the event type. since events can be posted multiple times and > > are not one-off, futures don't really apply. > > they do since they provide an easy way to chain and to keep order. But > okay, shall you prefer to optimize for "recurring" instead of > single-shot, that can be done with an internal data structure change. > I'd sill provide single shot callbacks for convenience. the event bus is for re-occurring events. That was always it's purpose. It should/would be optimized for that. If you look at the use of ecore event handlers almost every single one doesn't "register then delete itself when the first event comes in". So design for an optimize for this case, otherwise this will just be far more painful to work with having to re-subscribe inside every future. Also unlike futures there is no "else" (failure) case. This they just don't map nicely. > but more important and not mentioned here: types should be just > "Efl_Class". that's it, no register/query etc. You do need to be able to get the event object from the loop given a class at least. this is registration implicitly. I do need/want to put legacy ecore API on top somehow and so I have to be able to generate an int from this. > [...] > > >>* efl_loop_receiver_add(loop, Efl_Class event_class, cb, data); // > >> or better name to "add broadcast receiver, like event cb" > >>* efl_loop_receiver_del(loop, Efl_Class event_class, cb, data); // > >> or better name to "del broadcast receiver, like event cb" > >>* efl_loop_broadcast(loop, event_object); > >> > > > > close to what i was thinking. i was more thinking: > > > > // called once ever in an application: > > Efl_Loop_Event_Type efl_loop_event_type_new(Eo *loop, MY_EVENT_INFO_CLASS); > > // called to get the object representing that event type for that loop > > Eo *efl_loop_event_get(Eo *loop, Efl_Loop_Event_Type type); > > this is legacy, thinking backwards because you had that before. but that is what i need. i need to replace the ecore event but as eo stuff is depending on it and its' a singleton global. > You don't need that, just use Efl_Class.. that's it. no need to > "type_new", no need to "event_get". Use *any* Efl_Class, then: Yes - I thought it over more. a @class function can do this type-safely. pass in a loop obj and class and get an event type object back: event_type_obj = efl_loop_event_type_get(loop, MY_EVENT_CLASS); efl_event_callback_add(event_type_obj, EFL_LOOP_EVENT_TRIGGERED, mycall, data); the loop will create the event_type_obj on first use and store it and after that just return the same obj to everyone who gets it. so callbacks are managed with regular eo event callbacks on the same object. > - cb_add/del: operate on a hash Efl_Class -> list of cb > - broadcast: find Efl_Class in the hash, walk the list of cb > > > > // to listen to an event: > > event_type_obj = efl_loop_event_get(loop, event_type_id); > > efl_event_callback_add(event_type_obj, EFL_LOOP_EVENT_TRIGGERED, mycall, > > data); > > > > // to post an event: > > Eo *event_obj = my_event_info_event_new(event_type_obj); > > you don't need this, this is all handled by Eo. Just create *any* > object, post it to be broadcasted. > > > > efl_event_type_post(event_type_obj, event_obj); > > this is ok. > > > > every event type want you to create a class to represent it (they all must > > inherit a base event type class). the event type object is a factory that > > produces event objects (this means it also can act as a cache for them via > > del intercepts for example). the factory produces event objects of some > > specific type based on the class you define. you can fill in the obj with > > appropriate data at creation time, then when ready, post the event to the > > loop by the standard "post" method that is in the event type class. since > > the event type object knows what loop it belongs to, it will post to its > > owning loop. some time later as this queue
Re: [E-devel] ecore main loop -> efl_loop full convert
On Sun, 26 Nov 2017 10:20:26 -0200 Gustavo Sverzut Barbieri
said:
> On Sun, Nov 26, 2017 at 2:08 AM, Carsten Haitzler
> wrote:
> >> You don't need that, just use Efl_Class.. that's it. no need to
> >> "type_new", no need to "event_get". Use *any* Efl_Class, then:
> >
> > Yes - I thought it over more. a @class function can do this type-safely.
> > pass in a loop obj and class and get an event type object back:
> >
> > event_type_obj = efl_loop_event_type_get(loop, MY_EVENT_CLASS);
> > efl_event_callback_add(event_type_obj, EFL_LOOP_EVENT_TRIGGERED, mycall,
> > data);
> >
> > the loop will create the event_type_obj on first use and store it and after
> > that just return the same obj to everyone who gets it. so callbacks are
> > managed with regular eo event callbacks on the same object.
>
> hum... that works... usage would be something like?
>
> efl_event_callback_call(event_type_obj, EFL_LOOP_EVENT_TRIGGERED, data);
yes. or EFL_LOOP_EVENT_TRIGGERED i think will be a specific event per event
type (the class would define it) as this would produce typesafe callbacks in
languages like c++ etc.
i'm considering having a "not safe - requires knowing the type and using the
right methods" for c or js/lua etc. in addition to typesafe, for convenience.
this would probably have the universal "trigger" event. My idea at the moment
is to have a consistent design pattern here, just with the typed one being more
wordy in c/js/lua but safe in c++ and related langs (as typing can catch
errors).
> (that would make event dispatch synchronous), or:
>
>efl_loop_broadcast(loop, MY_EVENT_CLASS, data);
>
> which internally will queue {MY_EVENT_CLASS->data} and call
> efl_event_callback_call() at some specific main loop phase like
> before.
hmm no. i'd want to use the event_type_object handle here - place the event
object itself on the queue. looking up by class is just forcing extra overhead
in the api. using the event type object handle means the event can be queued
with the object handle of this object alongside the event object itself and
thus immediately call the right callbacks when it's processed on the queue
later on. so always "get" the event object by class first... store that
somewhere local then use that from then on (for that loop).
> I'd not oppose as it will simplify the logic a lot, basically you
> don't need to do anything at all -- all done by Eo. Including
> "walking/delete_me" logic...
but yes - internally it'd call the event_callback_call when the event on the
queue is processed "later on". the queue would just be a list of:
struct {
Eo *event_type_object;
Eo *event_object;
};
so every item in the queue knows what object to call the event callbacks on and
what to pass to this callback call (the event_object).
> then each loop contains a hash cls -> instance, return the instance
> (event_type_obj) or create and return for the first time.
i'd just avoid forcing the hash lookup every time if you can do the hash lookup
just once and store the object handle then... :)
> in that case, just be aware that MY_EVENT_CLASS for legacy is a single
> one: ECORE_EVENT_LEGACY_CLASS. It will contain "legacy_type: int"
> property, which uses the global integers to work on. Then
> ecore_event_callback_add() will connect efl_event_callback_call()
> using a proxy/wrapper, that will filter by "legacy_type", converting
> to the old dispatch system -- those globals still remain.
yup. i'd have to implement this legacy class and it'd have methods to get an
int for that object to then use the the legacy ecore event type. legacy event
types need to also support "don't call any LEGACY callbacks after this one on
the event" somehow as legacy can do this etc. etc.
> --
> Gustavo Sverzut Barbieri
> --
> Mobile: +55 (16) 99354-9890
>
--
- Codito, ergo sum - "I code, therefore I am" --
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] Blend2D - a gfx framework with dynamic pipelines support
On Sun, 3 Dec 2017 01:23:22 -0300 Vinícius dos Santos Oliveira said: > Hi all, > > I'd like to ask what is your opinion on this library[1]. > > It's a library where you call all the draw operations that comprise the > drawing pipeline, and, when you call `context_end`, the pipeline is > compiled (yep, JIT). Somehow exciting because it allows very interesting > optimizations. > > But it's also boring, because you have to recompile the whole pipeline > every time some value changes (i.e. probably every frame if you're writing > a game). > > But there is also plans to support a shader language (with a working > experimental code for a useless math functions language). With this support > added, you could compile the rendering pipeline only once and evaluate it > for every frame. > > The thing I like is support for Bézier curves. It's like OpenGL done for 2D > rendering. The API seems a lot like cairo, so it's mostly transparent > (except for the shaders). > > Maybe EFL could add a backend forked from SDL2 using this library to > generate the screen bits. Or maybe there is not enough info flowing the > higher layers to the lower layers to make this idea actually useful. > > Maybe some of these ideas could be stolen by the EFL project. > > I'd like to hear opinion from you guys about this project. You guys are > experienced with 2d gfx code and I'd love to hear anything you guys have to > say about this project. > > [1] https://blend2d.com/ Requiring c++ means then lower end systems will require libstd++ which will bloat our our requirements. no? from that view, i don't like it much. also i dislike the idea of a jit. i would prefer something like "pre-compile all permutations into special case functions then runtime call the right/matching one". the built-in jit is going to cause architecture support issues for us on various platforms where we do work (maybe not with optimized ASM but we work). a quick peruse of b2dpipe doesn't tell me what architectures are or are not supported easily... a quick look seems it needs "../asmjit" in a parent dir. this leads me to: https://github.com/asmjit/asmjit which says "x86/x64" only in the arch support. and that right off the bat would veto this as something we'd depend on. we'd need at least these architectures supported for me to begin considering: armv7,v8 x86,x64 ppc mips ... pretty much what luajit supports. i actually had been mulling writing such an "offline" code generator that generated c (with snippets of asm/asm intrinsics or macros for simd), then did like above. if blend2d was more like this... then it'd be worth looking at even if it had a c++ api. > -- > Vinícius dos Santos Oliveira > https://vinipsmaker.github.io/ > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - "I code, therefore I am" -- 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] [EGIT] [core/enlightenment] master 01/01: music-control - install properly with meson build with icon
On Sat, 2 Dec 2017 00:10:11 +0100 marcel-hollerb...@t-online.de said: > Hello, > > so it turned out that this is a ninja bug. > > Ninja has some sort of recompactination if the number of entries in the > .ninja_log and .ninja_deps files are getting too big, then it will cut > off a few, write that into a temp file, and rename that temp file later > to .ninja_log or .ninja_deps, if you ran exactly this time ninja as root > it will place .ninja_log and .ninja_deps as root owned files in the > directory instead of maintaining the old gid / uid of the file. I'm amazed it took us to discover this and you to fix it... ninja isn't exactly THAT new... :) is it that no one does regular "build as user, install as root" when using ninja? like this is the regular workflow with make like since... dinosaurs roamed the earth. > tldr: > There is a bugfix: > https://github.com/ninja-build/ninja/pull/1362 > > Greetings, > Marcel Hollerbach > > On Thu, Nov 23, 2017 at 08:57:20AM +0900, Carsten Haitzler wrote: > > On Wed, 22 Nov 2017 20:13:48 + Mike Blumenkrantz > > said: > > > > > I'm on fedora with meson 0.42.1 and ninja 1.8.2 > > > > Can you try doing the "build as user, install as root/sudo" and hit the > > issue and details exactly what files are owned by root at that point and > > what file the problem is with and why the permission problem is there? I > > just can't see the source of the issue in my build trees. > > > > > On Wed, Nov 22, 2017 at 1:08 PM Andrew Williams > > > wrote: > > > > > > > Hi, > > > > > > > > I'm on Arch and generally try to stay up to date so maybe they have > > > > fixed it? > > > > Mike? > > > > > > > > On Wed, 22 Nov 2017 at 15:55 Jérémy Zurcher wrote: > > > > > > > > > I can't reproduce that root owner ship issue right now. > > > > > I made the changes to my scripts on the 2017/08/17 > > > > > at that time on my archlinux boxes ninja was 1.7.2 and meson was > > > > > 0.41.2 since then ninja has been upgraded to 1.8.2, and meson to > > > > > 0.42.1 then 0.43.0 > > > > > maybe it has been fixed in one of them fixed now. > > > > > (but I won't dive into their respective repos to check that ;) > > > > > > > > > > > > > > > On Wednesday 22 November 2017 20:51, Carsten Haitzler wrote : > > > > > > On Wed, 22 Nov 2017 10:36:36 + Andrew Williams < > > > > a...@andywilliams.me> > > > > > said: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I'm glad that it is not affecting you. Jeyzu and I both seem to > > > > > > > have > > > > > hit > > > > > > > this issue (and I guess zmike too as described earlier). > > > > > > > Some times after a "sudo ninja install" I can no longer "ninja" > > > > > > > due > > > > to > > > > > > > permissions issues with files that have become root owned. > > > > > > > > > > > > > > It is unfortunate but it would be good to get a solution that > > > > > > > works > > > > > all the > > > > > > > time for everyone if possible. > > > > > > > > > > > > I checked what files were root owned. I currently don't see a reason > > > > why > > > > > it > > > > > > should fail. Someone show me a reason where it does fail (a file > > > > written > > > > > to as > > > > > > root has to be overwritten as a user or it cannot be deleted as a > > > > user). > > > > > I > > > > > > don't see it. perhaps its a bug in meson in an older version? or a > > > > newer > > > > > one? > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > On Wed, 22 Nov 2017 at 10:17 Carsten Haitzler > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > On Wed, 22 Nov 2017 10:33:05 +0100 Jérémy Zurcher > > > > > > > > > > > > > > > > > said: > > > > > > > > > > > > > > > > > Hi, > >
Re: [E-devel] Blend2D - a gfx framework with dynamic pipelines support
On Tue, 5 Dec 2017 22:50:21 -0300 Vinícius dos Santos Oliveira said: > 2017-12-03 10:19 GMT-03:00 Carsten Haitzler : > > > also i dislike the idea of a jit. i would prefer something like > > "pre-compile > > all permutations into special case functions then runtime call the > > right/matching one". > > > > I'm not familiar implementing gfx engines, but with my (small) background > on compilers and the giant notes page[1], I assume there are optimizations > that can't just be implemented otherwise. > > The API is like: > > ctx.draw_something1(); > ctx.draw_something2(); > ctx.draw_something3(); > ctx.end(); //< here the pipeline is compiled generally (at least for us) there is very little to be gained optimizing the "between something1/2/3". jits are good for this when you have realy small operations like cpu commands (a = b + 1 for example) and having a continuation of this where the same data stays in the same register etc. is a good idea and going to yield good speedups. for our graphics needs we generally do large batch operations like "do operation X with param a=x, b=y, c=z from rectangle X to rectangle Y" and X and Y rectangles are large regions of pixels (100's, 1000's or millions of them). trying to optimize for tiny operations on single pixels is a long tail of work that on average is going to yield very little in real life. this leads to the ability to pre-compile these operations. most of the time for params like a=0 you can special case 0, and 255 (or 1.0) and skip some muls or turn the op into a NOP entirely depending on what you are doing, but for all other values the generic math has to be done and you can do it with regular cpu (sometimes with some tricks up your sleeve to do simd-like ops with a regular cpu op as long as you don't need saturation math), or do some assembly version to do it. > In this API, the gfx engine can take info on cross-function information. If > draw_something3 completely hides draw_something2, one call can be > completely removed. It's actually boring, because you have to recompile the > whole pipeline every value changed, but the plans to support shaders will > change the situation[2][3]. > > There are drawbacks too. Evas already do interesting things and I just > don't know if this blend2d would actually be helpful. Evas is pretty damn > fast. And blend2d is whole CPU side, no GPU (but I still think it's > interesting because Bézier curves). sure. in some ways a jit is good. but pre-compiling is more generic and portable. but in the end the lack of architecture support for major architectures we support kind of puts it on the veto list. :( if it just generated some c src for all permutations and then we compiled it in... we'd at least have a portable one (without specialized assembly for mmx/sse, neon etc.). but it doesn't do this. :(. it does do mmx/sse etc. in the jit .. but only for intel and that is a problem. yes - they make good points about alignment cleanups for simd asm ops due to alignment needed and this expands library size. that is true. but it's not THAT onerous. they also make a good point of eliminating tmp buffers. we actually rarely use tmp buffers ourselves and have our operations already pre-coded, but we could do better. i was mulling doing a new sw renderer with tiles so yes - we'd have "temp buffers" but they'd all fit well inside l1 cache and that would be a big win when blending/operating over the same region multiple times as the destination at least will stay in cache for fast read-modify-write performance for blends. to do all of this i was mulling making a code generator to generate all the operations and functions from templates and so on... :) i have for a long time been mulling the idea of "texture compression" (s3tc, etc1/2 etc.style) even for software. allow more interesting pixel formats that reduce memory bandwidth needs significantly with constant storage cost. a sw engine can even be super smart and switch storage format tile by tile depending on what works best for that tile. often regions of an image are "empty" and thus there is no need to even store any pixels for it - just a flag of "this is transparent" or "this is a single ARGB color" and then when rendering these regions can optimize their src fetches significantly... and save memory to boot. > Oh, and thanks for replying to my email. It was just a different point of > view, just as I wanted to have. > > [1] https://blend2d.com/notes.html > [2] https://blend2d.com/roadmap.html yes. they say they want to support arm. but still there's ppc, mips, ... and more... :) there is no way i'd want to maintain 2 rendering engine paths in the long run and short term should be very short. i&#x
Re: [E-devel] What are we going to release?
On Wed, 06 Dec 2017 15:13:05 +0100 Daniel Kolesa said: > On Wed, Dec 6, 2017, at 14:26, Andrew Williams wrote: > > Hi all, > > > > As our last release was over 4 months ago I think we really need to > > figure > > what the next release will be, and when, so we can start focusing on > > making > > that subsection of our work releasable. > > > > Clearly we are not going to get the interfaces completed any time soon. > > The > > list of things to port keeps getting longer and we have too many > > outstanding patches to count. I have heard suggestions that we could > > release a subset, for example Efl_Core and Efl_Net now that they we have > > the Efl namespace split into groups. > > This would mean releasing the API ( > > https://www.enlightenment.org/develop/api/start) that is prefixed efl_io, > > efl_net, efl_event or efl_loop and that's about it (as well as eina and > > eo > > which need to get merged into the non-legacy docs somehow). > > > > Is this a good approach? Right now it seems like we need to focus on > > completing portions of this and cut a release of some sort so that we can > > have people look at usage, bindings and porting existing code. I'd love > > to > > get our website updated to filter just the APIs we plan to release soon. > > And then generate another section for the work-in-progress completion of > > interfaces... > > Hi, > > I told you on IRC already but I'm going to say it here publicly - > personally I don't think it's a good idea to release APIs unless we're > sure that it's really the API we want (i.e. it can be defined in Eolian > once it's stable, it can be used for bindings and it's > real-world-tested, i.e. we're sure of its practicality). I don't see any > real benefit in releasing a subset of our APIs, only potential issues. I agree with Daniel here. Releasing just for the "need to release something". These efl core/net API's rely on sharing concepts, interfaces etc. with the rest of efl if we are to do it right, and that is still evolving as things solidify. There is no value at all in releasing a subset like this. It's useless without having a large enough set of epi's to usefully build applications from top to bottom. Sure - ignore efreet, ethumb, eet etc. in eo API for now. We could release eo API's without these once eo API is settled on and releasable. But certainly not some tiny subset like above. I'm currently working on efl_loop and related in an effort to pad out this bit and have something for people to look and and reviews, comment on etc. But the past week or so I've been busy with other things. > However, I do think it's maybe a good subset to aim for stabilizing > first - maybe we could make use of it to set some kind of better > direction to make our progress faster. > > D5 > > > > > Thanks, > > Andrew > > -- > > http://andywilliams.me > > http://ajwillia.ms > > -- > > 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 > -- - Codito, ergo sum - "I code, therefore I am" -- 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] What are we going to release?
On Wed, 06 Dec 2017 19:45:39 -0500 Cedric Bail said: > Hi, > > > Original Message > > Subject: Re: [E-devel] What are we going to release? > > Local Time: December 6, 2017 6:13 AM > > UTC Time: December 6, 2017 2:13 PM > > From: dan...@octaforge.org > > To: enlightenment-devel@lists.sourceforge.net > > > > On Wed, Dec 6, 2017, at 14:26, Andrew Williams wrote: > > > >> Hi all, > >> As our last release was over 4 months ago I think we really need to > >> figure > >> what the next release will be, and when, so we can start focusing on > >> making > >> that subsection of our work releasable. > >> Clearly we are not going to get the interfaces completed any time soon. > >> The > >> list of things to port keeps getting longer and we have too many > >> outstanding patches to count. I have heard suggestions that we could > >> release a subset, for example Efl_Core and Efl_Net now that they we have > >> the Efl namespace split into groups. > >> This would mean releasing the API ( > >> https://www.enlightenment.org/develop/api/start) that is prefixed efl_io, > >> efl_net, efl_event or efl_loop and that's about it (as well as eina and > >> eo > >> which need to get merged into the non-legacy docs somehow). > >> Is this a good approach? Right now it seems like we need to focus on > >> completing portions of this and cut a release of some sort so that we can > >> have people look at usage, bindings and porting existing code. I'd love > >> to > >> get our website updated to filter just the APIs we plan to release soon. > >> And then generate another section for the work-in-progress completion of > >> interfaces... > >> > >> Hi, > >> > >> I told you on IRC already but I'm going to say it here publicly - > >> personally I don't think it's a good idea to release APIs unless we're > >> sure that it's really the API we want (i.e. it can be defined in Eolian > >> once it's stable, it can be used for bindings and it's > >> real-world-tested, i.e. we're sure of its practicality). I don't see any > >> real benefit in releasing a subset of our APIs, only potential issues. > > We have been working on EFL interfaces for years now. Literrally. We have to > do a release in the next 6 months. The main question is how to get there and > have something good enough for everyone. > > My current take is that we finish cleaning up Efl_Core and Efl_Net for a beta > release (which mean no further change except if something is really bad) and > do an EFL release with that. This would make it possible for people who want > to do binding to start working on it and report problem they have during 1.22 > release cycle. This would be the only time we could still break our API in my > point of view, but only if it is asked by binding developers. Finally for EFL > 1.22, we will release an Efl_Ui component. and everything below will also be > marked stable. ALL of eo/interfaces is already released as "beta". has been now for a very long time. how does this change anything? we have NEEDED to make changes that have broken what we have. i don;'t see this as any change to the current status. > This mean the remaining question is what is left to do for this. On my side : > - Remove reference to graphic interface when including Efl_Core/Efl_Net. > - Finish migration to Eina_Future > > If you have still some stuff on your plate, you should let us know. I do feel > that for helping Stefan we should open a ticket to track this last task until > a release. > > 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 > -- - Codito, ergo sum - "I code, therefore I am" -- 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] What are we going to release?
On Thu, 07 Dec 2017 08:54:05 + Andrew Williams said: so what applications can you build only with efl core and efl net and nothing else? zero applications will be built with these. it will not be tested. history tells me so. BUT it will tie our hands in making changes. so what value does this provide? none to any developers who know that the api is STILL unstable and changes might be made, unless we guarantee NONE will be... and then if NONE are broken, our hands are tied. i'm speaking from experience here. i made eet 1.0 long (years) before ecore, evas, etc. etc. ... and people didn't go using it. been there. done that. and by the time the others were ready i was already going "crap - i shouldn't have done that" because eet had to hold legacy file format support (and still does) that was deprecated already in efl before edje 1.0 was done. what we have now i think is the best we can do. > Hi, > > To say that it is publicly available behind a BETA flag is one thing, but > to call it a Beta Release is quite a stretch. To reference The Next > Generation Lexicon: "Beta phase generally begins when the software is > feature complete but likely to contain a number of known or unknown bugs.". > Given the current state of the interfaces I would say that to treat it like > that is exceptionally generous. I have never been anywhere where the > developers or users have been told "It's in beta - the APIs will change - > we don't care" which is common parlance around here. > > I think it's unfair to say that releasing a subset has "no value". The APIs > described allow you to build a complete application - albeit without a > graphical front end - which is a great start, even a solid foundation. With > a little more work we could have Efl.Canvas and Efl.Gfx in there to get > early access to the new graphical APIs. It seems that Efl.Ui is sinking the > most time and we are having to rewrite areas of it as the underlying > libraries change. Surely nailing the underpinnings and releasing them gives > us a stable platform to deliver on. > > Calling for release discussions seems required to focus us. As everyone > acknowledges we are a team spread very thin and if we continue to have > little or no direction for release we will continue to work on what is > interesting and not to wrap up an API that is actually usable and reliable > to anyone. > > Right now I don't think it's clear what we are trying to achieve. It would > be a death knell to our chances of being taken seriously if we once again > take 10 years to do a major upgrade. > > Regards, > Andrew > > On Thu, 7 Dec 2017 at 01:22 Carsten Haitzler wrote: > > > On Wed, 06 Dec 2017 19:45:39 -0500 Cedric Bail said: > > > > > Hi, > > > > > > > Original Message > > > > Subject: Re: [E-devel] What are we going to release? > > > > Local Time: December 6, 2017 6:13 AM > > > > UTC Time: December 6, 2017 2:13 PM > > > > From: dan...@octaforge.org > > > > To: enlightenment-devel@lists.sourceforge.net > > > > > > > > On Wed, Dec 6, 2017, at 14:26, Andrew Williams wrote: > > > > > > > >> Hi all, > > > >> As our last release was over 4 months ago I think we really need to > > > >> figure > > > >> what the next release will be, and when, so we can start focusing on > > > >> making > > > >> that subsection of our work releasable. > > > >> Clearly we are not going to get the interfaces completed any time > > soon. > > > >> The > > > >> list of things to port keeps getting longer and we have too many > > > >> outstanding patches to count. I have heard suggestions that we could > > > >> release a subset, for example Efl_Core and Efl_Net now that they we > > have > > > >> the Efl namespace split into groups. > > > >> This would mean releasing the API ( > > > >> https://www.enlightenment.org/develop/api/start) that is prefixed > > efl_io, > > > >> efl_net, efl_event or efl_loop and that's about it (as well as eina > > and > > > >> eo > > > >> which need to get merged into the non-legacy docs somehow). > > > >> Is this a good approach? Right now it seems like we need to focus on > > > >> completing portions of this and cut a release of some sort so that we > > can > > > >> have people look at usage, bindings and porting existing code. I'd > > love > > > >> to > >
Re: [E-devel] KiwiIRC callouts
On Thu, 07 Dec 2017 15:09:21 + Andrew Williams said: > Hi, > > Did anyone know that the KiwiIRC client on our website is calling out to > https://www.gosquared.com/ and https://www.scorecardresearch.com/? > Does anyone know if we activated these extensions? I have no idea what > those sites do or what data they are collecting. we don't decide that. that's part of the www kiwi irc client. the irc client is a small bit of js that simply auto-selects a random irc nick, then creates an iframe from https://kiwiirc.com ... everything else is the kiwi irc client itself doing this. the only way to avoid this is to ... self-host our own back-end and hook that into freenode. the kiwi irc client as provided by kiwiirc.com has very limited options. very limited. > Thanks, > Andy > -- > http://andywilliams.me > http://ajwillia.ms > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ----- Codito, ergo sum - "I code, therefore I am" -- 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] What are we going to release?
On Thu, 07 Dec 2017 13:45:51 + Andrew Williams said: Without a guarantee of no changes then you don't provide anything stable to build on top of. It's no different to what we do now. We could just say "we think these interfaces are ok now - you can try using them but we might still break them" which is is not some special beta release. it's just providing a "we think its more stable now" assessment. but still if it's just what you were saying then what apps can be written using those api's - and will they be? > Why does it have to be black and white? releasing does not "guarantee no > changes", it probably does need to guarantee backward compatibility. The > challenge I see with our current situation is that we have published "beta" > which is not even close to stable and now don't have a clear next step to > get people involved. A "release candidate" might be an obvious step which > comes as part of a release plan, which is what I wanted to discuss. what we have is a release candidate so to speak that is clearly showing its state - it's not stable. trying to release something as stable that is NOT (call it a release candidate or whatever) is just being dishonest. > I think that EFL and our community is in a different place to where it was > years before ecore. We should learn from (everyone's) experience and figure > how to apply that to our current situation. Our current reality is that > companies with real products want to build on what we have. That's pretty > exciting I reckon. and they need the full stack done to build them. not just some small sub-bits. thus i point out what i did already... what apps with such a subset of api's (efl core/loop/net?). they can't even build things with efl.gfx. they need efl.ui and even then the efl.ui we are proposing means them losing several widgets they have used before etc. ... so that's already a sacrifice. > Until we have a release of the new API that people can actually start > relying on being somewhat stable we are expecting them to use only the old > API. In the meantime we have most active development on it's replacement. > We are basically saying "you can use the old stuff, but you'll need to port > later - or you can try and use the new stuff, which requires regular > updating to keep up". To me this looks like there is no practical way that > we can encourage new people to rely on EFL. This makes me sad. because that is the state we're in. like it or not we're there. the way out is to work on it, not to give people a false sense of security over a small subset of interfaces that we aren't even sure will stay stable. even a single abi change will be a "showstopper" for the example above (companies using efl). just 1 is a dead end. thus you either guarantee abi stability totally, or it's all bets off. > Should we instead figure when we might start releasing and set an > expectation to the public? Something like "come back in 2019"? well we hoped to finish in 2016, then by end of 2017 ... we have a better chance now as people are really focusing on it, but i actually suspect 2019 is a safe bet. mid 2018 might be "optimistic" and end of Q1 2018 is "totally crazy optimistic if the world all aligns right". > Andrew > > On Thu, 7 Dec 2017 at 10:37 Carsten Haitzler wrote: > > > On Thu, 07 Dec 2017 08:54:05 + Andrew Williams > > said: > > > > so what applications can you build only with efl core and efl net and > > nothing > > else? > > > > zero applications will be built with these. it will not be tested. history > > tells > > me so. BUT it will tie our hands in making changes. so what value does this > > provide? none to any developers who know that the api is STILL unstable and > > changes might be made, unless we guarantee NONE will be... and then if > > NONE are > > broken, our hands are tied. > > > > i'm speaking from experience here. i made eet 1.0 long (years) before > > ecore, > > evas, etc. etc. ... and people didn't go using it. been there. done that. > > and > > by the time the others were ready i was already going "crap - i shouldn't > > have > > done that" because eet had to hold legacy file format support (and still > > does) > > that was deprecated already in efl before edje 1.0 was done. > > > > what we have now i think is the best we can do. > > > > > Hi, > > > > > > To say that it is publicly available behind a BETA flag is one thing, but > > > to call it a Beta Release is quite a stretch. To reference The Next > > > Generation Lexi
Re: [E-devel] KiwiIRC callouts
On Fri, 8 Dec 2017 06:41:32 +0100 Jonathan Aquilina said: > There is another web based irc client that i know of im not sure if it > would be a better alternative for the website. > > https://qwebirc.org/ > > Never set it up but used it quite a bit to get on freenode. If the > current client is an issue it might be something worth looking at. that'd be the same as kiwiirc. we'd have to install and host it ourselves and have it connect to freenode. we'de have to negotiate with freenode to whitelist our server ip to disable user/connection limits (freenode does this) etc. so same story. have to self host. > On 08/12/2017 02:11, Carsten Haitzler wrote: > > On Thu, 07 Dec 2017 15:09:21 + Andrew Williams > > said: > > > >> Hi, > >> > >> Did anyone know that the KiwiIRC client on our website is calling out to > >> https://www.gosquared.com/ and https://www.scorecardresearch.com/? > >> Does anyone know if we activated these extensions? I have no idea what > >> those sites do or what data they are collecting. > > > > we don't decide that. that's part of the www kiwi irc client. the irc > > client is a small bit of js that simply auto-selects a random irc nick, > > then creates an iframe from https://kiwiirc.com ... everything else is the > > kiwi irc client itself doing this. the only way to avoid this is to ... > > self-host our own back-end and hook that into freenode. the kiwi irc client > > as provided by kiwiirc.com has very limited options. very limited. > > > >> Thanks, > >> Andy > >> -- > >> http://andywilliams.me > >> http://ajwillia.ms > >> -- > >> Check out the vibrant tech community on one of the world's most > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >> ___ > >> enlightenment-devel mailing list > >> enlightenment-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > > > > -- - Codito, ergo sum - "I code, therefore I am" -- 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] KiwiIRC callouts
On Fri, 08 Dec 2017 08:58:53 + Andrew Williams said: > Hi, > > Perhaps I should rephrase my question. Are we happy with these callouts? > For some reason it's proximity to our user's chat history makes me hesitate. I personally am not too bothered. It's the price of the service we get for free. You're talk of adding google analytics is the same thing pretty much. handing data to google to track and do with as they pretty much feel like. If we're being paranoid for our www users then don't use GA either. If GA is fine, the the kiwiirc stuff that's there not is fine IMHO. > https://www.theguardian.com/technology/2012/apr/23/scorecardresearch-tracking-trackers-cookies-web-monitoring > > Thanks, > Andrew > > On Fri, 8 Dec 2017 at 01:12 Carsten Haitzler wrote: > > > On Thu, 07 Dec 2017 15:09:21 + Andrew Williams > > said: > > > > > Hi, > > > > > > Did anyone know that the KiwiIRC client on our website is calling out to > > > https://www.gosquared.com/ and https://www.scorecardresearch.com/? > > > Does anyone know if we activated these extensions? I have no idea what > > > those sites do or what data they are collecting. > > > > we don't decide that. that's part of the www kiwi irc client. the irc > > client is > > a small bit of js that simply auto-selects a random irc nick, then creates > > an > > iframe from https://kiwiirc.com ... everything else is the kiwi irc client > > itself doing this. the only way to avoid this is to ... self-host our own > > back-end and hook that into freenode. the kiwi irc client as provided by > > kiwiirc.com has very limited options. very limited. > > > > > Thanks, > > > Andy > > > -- > > > http://andywilliams.me > > > http://ajwillia.ms > > > > > -- > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______ > > > enlightenment-devel mailing list > > > enlightenment-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > -- > > - Codito, ergo sum - "I code, therefore I am" -- > > Carsten Haitzler - ras...@rasterman.com > > > > -- > http://andywilliams.me > http://ajwillia.ms -- - Codito, ergo sum - "I code, therefore I am" -- 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] Interfaces API not in EFL namespace
On Fri, 08 Dec 2017 18:35:45 + Andrew Williams said: > Hi, > > I've been going through our API documentation generation (for Eo API) and I > found some interesting numbers. We all know there is a lot to do in terms > of porting legacy to Eo API but I found a lot of API that is in Eo but is > not in the Efl namespace (i.e. Ecore / Elm etc) which I assume will also > need to be ported. > > The total number of "legacy eo" classes and types are as follows (with > percentage of total in each category) > > === CLASS SECTION: 442 === > > Classes: 157 (44%) > Interfaces: 3 (3.5%) > Mixins: 8 (24%) > Events:274 (48%) > > === TYPE SECTION: 807 === > > Aliases:62 (85%) > Structs:46 (52%) > Struct fields: 71 (35%) > Enums: 92 (48%) > Enum fields: 534 (40%) > > Or to summarise 43% of the Eo definitions are not in the Efl namespace. > This is a lot of additional work to the new class creation - do we have > tickets to track this all as well? many will never go to eo. many elm widgets have been decided to "drop for eo api". for example. so it'd have to be on a case by case basis really. > Have a happy weekend! > Andy > -- > http://andywilliams.me > http://ajwillia.ms > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- 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] What are we going to release?
top working. The new API is designed to allow for a smooth transition. It is > designed to allow you to mix old and new together. This way, you can already > build a useful application by building with Efl_Core, Efl_Net and Elementary. > This is fine. it's not about "trying to release all at once". it's about not painting ourselves into a corner. not limiting ourselves before we really need to. every release we do means we stop doing eo work and instead stabilize a release. the more we do the more we push a final result into 2019. without a significant amount of the interfaces api available you won't really get much, if any, valuable feedback, and instead simply lose at least a few months of work time into release work. (1 month per release at least). i don't see how this gets us to our goal better or sooner than what we are doing now. what i do see is: 1. getting there later 2. not gaining anything really valuable in return for that delay but here's my take... the above is my advice, but delay-wise... i'm not responsible. but mark my words that the goal that MATTERS - interfaces that can be used in BINDINGS like C#, C++, JS, LUA etc. will only get delayed ... and you know well enough how much a release delays. we have a whole mountain of new coverity complaints. any eo api to be "stabilized for release" needs a lot of attention in review and actual use before that release goes out if you want any kind of stability guarantee to it. and you know full well that just these few api's are of nil use to the consumers of bindings like above until there is a LOT more there. but if you wish to take the risk and the blame when things get delayed... you go ahead. all i want is proof of actual use in the wild like you claim, because unless there is such proof, no lessons will ever be learned from this. think of it as a "KPI". proof that the "stable beta api" is used without the current unstable beta #define and so on... in more than a few trivial places. > 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 > -- - Codito, ergo sum - "I code, therefore I am" -- 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] What are we going to release?
r next release. Trying to use .eo to make your own > objects, forget about it, it is going to be broken too. Basically, at this > point only people that can spend their full time on it are the one keeping up > with it (and barely). eolian and eo are still a moving target to the point you cannot do this. the c+ + bindings break regularly. i've given up building them so i can even run make check. talk to q66. we're not even close on depending on eo. until the bindings we have stop breaking due to eolian or eo changes for a few months (1-3m) ... we're not even close. > If we want to get more people eyes on this and get things settle it is time > to stop moving dirt around like crazy. It is important to not forget that a > core feature of this new API is that it is compatible with the old one. This > is done to allow for a smooth transition path. It also means we don't need to > release all of our API right away, we can turn on the light on a progressive > path. > > I see value in stabilizing everything below Efl_Core.h and Efl_Net.h in the > sense that we can maybe start to get people to look at what we have done, > build bindings and give us feedback. Application can start to rely on some of > the feature already of Eo. This will give us chance to improve the API that > is yet to come. then put it behind another #ifdef flag and i want to see actual evidence people use this new flag other than "us". because i bet it'll be no one or as close to no one as practically worth talking about. you know how these things go. put things in a branch? it's untested until it hits master. if it's an opt-in with effort ... nothing will change. and if it's "might still change" and not actually locked down then you'd be an idiot to use/try the api in anything as you'd depend on something that may break abi. you take a big risk. > There will be mistake, their will be dead API, nothing is ever perfect and > even if we wait another 6 months, a year to release this bits there would > still be things that are not perfect. So let's start releasing small bits > that are nearing being good enought and see where we are completely wrong, > before we release everything and we end up with a massive amount of errors. > Focusing our energy on releasing the lower bits will help us to get to a > point where we can release the next layer. but you either break the api/abi if needed in which case anyone who did try the api is REALLY annoyed. distros like suse (ask simotek) will report abi breaks and if needed patch the api out so abu breaks are avoided. ask simotek about eflete/enventor and packaging. if anything will change at all. even small things, then it's a problem. the only way to do this is to guarantee NO changes and that paints us into a corner. see above about the breaks still happening. > 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 > -- - Codito, ergo sum - "I code, therefore I am" -- 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] What are we going to release?
On Sat, 09 Dec 2017 13:38:51 + Andrew Williams said: > This has become a circular argument, as many do around here, vis: > *) people are asking for us to try and agree on stable areas of the API so > we can start testing it externally > *) we won’t do that until there is proof that people are using our beta > APIs (which are currently unstable). > How can we break this loop? which people where are asking for a release of a small susbet of the api? show me. > I cannot believe that all of the new APIs are completely unstable until we > release - that is basically a house of cards that we hope one day will > become rigid. Some of what we have is more mature than other things - but > every single API we add immediately goes into the BETA flag for next > release.. you are asking for a change of plans that everyone working on eo/interfaces agreed on. you have to make your case for that CHANGE. don't tell me "people are asking". show me the emails here asking, and from who. show me the irc logs or the phab tickets. i'm not talking about the full release of what was planned but the subset you mentioned. see above. those changes come with a cost (locking yourself in). we'd be stupid to pay the cost with no evidence beyond your comment "people are asking". not to mention it'd also be ignoring the previous agreement on what to do. until the people working on eo/interfaces can ALL come to a consensus... nothing is going to change. and there is no input from most of them at this point, and no overwhelming evidence to ignore any input from them if it were to come. > If we cannot make any release in the way previously discussed then we > absolutely should have some other way of illustrating our confidence in an > API. Therefore an alternative I propose is to add an ALPHA flag (which is > mostly what BETA feels like at the moment) where new Eo goes and those > marked as BETA are the classes we feel could be eliciting feedback. > This way we are able to show where we know we have not tested as much and > can show a journey through creation, testing and integration into the BETA > area. > > Without this we are just hoping that some day all our classes will be > stable so we can roll a release... > > Andrew > On Sat, 9 Dec 2017 at 12:48, Carsten Haitzler wrote: > > > On Fri, 08 Dec 2017 19:06:47 -0500 Cedric Bail said: > > > > > > Original Message > > > > Subject: Re: [E-devel] What are we going to release? > > > > Local Time: December 7, 2017 5:06 PM > > > > UTC Time: December 8, 2017 1:06 AM > > > > From: ras...@rasterman.com > > > > To: Andrew Williams > > > > Enlightenment developer list < > > enlightenment-devel@lists.sourceforge.net> > > > > > > > > On Thu, 07 Dec 2017 13:45:51 + Andrew Williams > > a...@andywilliams.me > > > > said: > > > > > > > > Without a guarantee of no changes then you don't provide anything > > stable to > > > > build on top of. It's no different to what we do now. We could just > > say "we > > > > think these interfaces are ok now - you can try using them but we might > > > > still break them" which is is not some special beta release. it's just > > > > providing a "we think its more stable now" assessment. > > > > > > I am thinking of a stronger commitment on our part here. Basically as I > > said > > > in my email above, if a binding doesn't report a real big problem with > > what > > > is under that RC umbrella, then we do not break it. > > > > unless it's "absolutely will not break at all" then it's really no better > > in > > the end. > > > > > I am afraid that for a lot of this lower level, we are now starting to do > > > what we were doing before we release EFL 1.0. Trying to make it perfect > > > without having ever spend the time to prepare a proper release. We need > > to > > > focus and get things out. > > > > > > > but still if it's just what you were saying then what apps can be > > written > > > > using those api's - and will they be? > > > > > > EFL apps already exist. They can get migrated to the new API. That is the > > > main target of this release. > > > > other than some mechanical "sed work" like s/evas_object_del/efl_del/g ... > > which buys nothing really useful... what is really going to be done? and > > what > > will this demonstrate to us or anyone else api-wise? not much
Re: [E-devel] What are we going to release?
On Sun, 10 Dec 2017 09:35:05 + Andrew Williams said: > Hi, > > Apologies I was not aware of these plans that everyone agreed on. Can you > please point me to this plan? It is very difficult to make a case for > change without knowing the preceding plan that would need to change. that all of eo/efl interfaces is behind the same beta flag until done. it's the state you see now. there were and are no plans to pick and choose some interfaces to release as stable, and some not. at one point we were talking about making just eo stable but then we realized it needed lots of changes and this has never come up again. you want the plan? see the tickets for interfaces. that's the work to be done and the work done on the interfaces themselves feeds back to the lower levels all the time. > To require irc logs or ML emails asking for this change is to imply that > we, the community, are serving just this community - I thought we were > looking bigger picture than that. It would be a violation of trust to paste > private conversations or concerns into this email chain, perhaps those who > are in agreement will contribute to this conversation. if you're using them as a justification, then they should be quoted here. > I am confused about what you mean regarding consensus. I have seen no > discussion bar this about release plans or indeed the plan / priority for > interfaces. If we could publicly discuss or collaborate on that this would > be a lot easier. I agree that there has been little discussion on this that's because it is one blob of work and the "let's release different b its at different times" is not there because that was not agreed on, otherwise it'd be in tickets. what was agreed on is what is already there in code and tickets. the things to be eoified (well it is a rough list that gets more refined as time goes on). it's all behind the same ifdef. ... if you want to change this direction and state... you should convince many people it's a good idea. i, so far, am not convinced it is. you'd need to convince more than me too. > thread but from your first email it seemed like it would be a waste of time > discussing so I’m not surprised. This does not detract from the number of > people who have spoken to me that are disappointed we cannot be thinking > about releasing some of our work. every time i disagree you seem to take it as a "i give up". so what should i do" just shut up and pretend to agree? what is the point of a discussion when it has to become a "let me just lie and not express what i think to make someone else happy"? you expressed an opinion. i expressed a counter one. i believe the value does not justify the cost. i made that clear. convince me otherwise. otherwise this is not a discussion. > However if the plan you described is publicly available then I apologise > for the confusion. I can point these individuals to the document and we can > think harder about what the smallest change could be that provides a > solution for everyone. > > Thanks, > Andrew > On Sun, 10 Dec 2017 at 01:09, Carsten Haitzler wrote: > > > On Sat, 09 Dec 2017 13:38:51 + Andrew Williams > > said: > > > > > This has become a circular argument, as many do around here, vis: > > > *) people are asking for us to try and agree on stable areas of the API > > so > > > we can start testing it externally > > > *) we won’t do that until there is proof that people are using our beta > > > APIs (which are currently unstable). > > > How can we break this loop? > > > > which people where are asking for a release of a small susbet of the api? > > show > > me. > > > > > I cannot believe that all of the new APIs are completely unstable until > > we > > > release - that is basically a house of cards that we hope one day will > > > become rigid. Some of what we have is more mature than other things - but > > > every single API we add immediately goes into the BETA flag for next > > > release.. > > > > you are asking for a change of plans that everyone working on eo/interfaces > > agreed on. you have to make your case for that CHANGE. don't tell me > > "people > > are asking". show me the emails here asking, and from who. show me the irc > > logs or the phab tickets. i'm not talking about the full release of what > > was > > planned but the subset you mentioned. see above. those changes come with a > > cost > > (locking yourself in). we'd be stupid to pay the cost with no evidence > > beyond > > your comment "people are asking". not to mention it'd also be ignoring the > > previous agr
Re: [E-devel] What are we going to release?
On Sun, 10 Dec 2017 23:41:20 + Andrew Williams said: > Hi, > > I had not intended to seem like I was giving up - I am pushing hard to try > and have this discussion as I think it is important. The paragraph you > referenced was intending to point out that our mailing list discussions do > not have an open nature to them so others feel it is not worth > contributing. When words like “guarantee” and “zero value” are used can you > not see how that could be received? because i have seen history and those words are the truth given history and my experience. ok "zero value" is like "it's worth a few cups of coffee when we're looking at buying a car". not literally zero but very very very low value compared to the big picture. yes. they are strong words. i feel strongly about this. are you saying that i am not allowed to feel strongly about this and should tone everything down just in case you get discouraged. i have to pretend to not feel strongly and be dishonest about my opinion? i expected better of you. i KNOW who wants interfaces in things like c# and a subset is useless to them. they have to be able to build entire apps with the ui in that language. it's all of it or not bother. this applies to js, lua and python too. i also know that even the core is unstable and far from settled. that means the chances of a break are high. this means that apps cant really use any of eo and interfaces as the changes of "it will break" are close to 100%. somewhere, somehow something will break - even if just 1 or 2 small things, but enough where "i upgraded efl and app X now crashes, or doesn't start because symbol X not found" will be the result. it only takes one small thing to cause that. lots of the core interfaces like on efl loop are not re-using shared interfaces yet and actually should probably be doing just that. until we implement more of the higher level AND then stand back and go "there's a design pattern there. let's unify it under a single interface everyone inherits and shares so it's consistent" there will be such changes. i think you're jumping the gun on such a release without the attendant warnings of "this stuff will break". i have no confidence in what you proposed to release as stable as being solid enough to put the label on it you want - not now or even in a few weeks from now. perhaps in 2 or 3 months, but that's about the same timeline for getting all of the "target api set" up through ui done too as much is being done in parallel. then we'd need ~1 month for a release cycle at least. probably longer if we want to expose all these new eo based things as "stable beta". it's far more important to get the core lower levels right as everything is built on top, than to get leaf nodes in the class tree right... thus why they would require more conservative attention. > As I have pointed out before the interface parent ticket has new tickets > added faster than we are closing existing ones. I see also that completely > broken eo widgets are being pushed into master (see efl.ui.panes for > example) and abandoned. With that in mind can we realistically expect to > release the whole lot in one go this decade? it has to. it actually has to be done in the next few months. like ~2-3. not a subset. everything including the ui classes. yes. stuff is there that is broken. the panes actually did work. last i knew they worked, then ANOTHER change somewhere else in evas broke them, ami fixed them, now they re-broke and he didn't know. they were not pushed AS broken widgets... > I will work with the folk I have been chatting with to see if I can pull > together the requirements that are driving the desire to start building on > eo api rather than legacy. without them chiming in and saying why they want a small subset released and what they at all intend to build with it... i am sticking to my position on this - that it's dangerous to mark as stable (beta stable as you say). dangerous for the work being done, dangerous to extending timelines for the work as a whole, dangerous to people then using those api's as given the past it is a nigh guarantee that those api's will have to break. a lot changed and broke AS interfaces were worked on and we realized we need to do something in a certain way or need a feature or need to redesign something etc. ... so until those higher level changes have settled down at least to small things like arguing over a property, method or event name... i wouldn't say eo is releasable. futures still are not a done thing and they are central to eo's core. without them being actually used first by people able to stomach a break and redesign if it has to happen... chasing a "let's release as stable beta some subset of core" is a bit of a pipe dream
Re: [E-devel] Unified API docs
On Mon, 11 Dec 2017 17:37:10 + Andrew Williams said: Looks good, but I think it's too trimmed. Maybe it's just that in every language I know a method, function, etc. also lists its inputs and outputs (return and argument names/types). and not having that there even in shorthand makes it harder to know at a glance if that is what I want. Efl.Text.Markup.markup (get, set) Efl.Text.text (get, set) [Overridden here] for example. what does it take? a string? i guess so... but i'm not sure. 1 parameter or 2 what about: Efl.Ui.Layout.theme (set) what does this take to set? i happen to know it's a string... but knowing at a glance what these are would make these far more useful. Also I notice sorting is odd. The protected methods are sorted separately to the rest. Wouldn't it make sense to at least separate off a "protected" section then instead of adding protected to each entry? Just for "aesthetics" wouldn't it be also nicer to put the list of methods/properties in a table? If we're sorting by parent class (Efl.Ui.Cursor, Efl.Ui.Layout etc. etc.) why repeat this per line? start a table row with the class name then list all the properties/methods over the next N lines (perhaps indented) like: | Efl.Text.Markup| | | cursor_markup_insert | method|| | | markup | get | set || | Efl.Text | | | text | get | set | [Overridden here] | | Efl.Ui.Autorepeat | | | autorepeat_enabled | get | set | [Overridden here] | | | autorepeat_gap_timeout | get | set | [Overridden here] | | | autorepeat_initial_timeout | get | set | [Overridden here] | | | autorepeat_supported | get | | [Overridden here] | | Efl.Ui.Base| | | language | get | set || | | mirrored_automatic | get | set | [Overridden in Elm.Widget] | | | mirrored | get | set | [Overridden in Elm.Widget] | without the actual table border lines - keep it blank with padding to space it out, perhaps the "Efl.Ui.Base" class inheritance headers having a different background color for the table row to delineate sections more easily. removal of the parent class to a header should create a bit more room for the arguments and returns i mentioned above... similarly for events? just suggestions. > Hi, > > I have done some significant updates to the new API docs. The layout still > wants a little tweaking but they should be more readable than they were > before. I've trimmed the fat out of all inherited members as discussed > before. > > The result is that a page like > www.enlightenment.org/develop/api/efl/ui/button which has no members of > it's own has gone down from 300k to 128k (according to curl). > > This should help our average page load time a lot - and it needs work as we > are sitting at 4sec currently! > > Let me know if you see any problems with the new trimmed rendering. > > Thanks, > Andy > -- > http://andywilliams.me > http://ajwillia.ms > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- 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
