[E-devel] [RFC] efl_uri_set and efl_file_set

[Cedric BAIL]

Hello,

So there has been a lot of confusion about what asynchronous request
and promise/future bring. The biggest one is that people have
missleading idea about what efl_uri_set/efl_file_set will be looking
like with them. Kind of normal because there is no code handling this
function in tree and no example of course.

The following email is kind of what it should look like when it is
done. It is still to be implemented and detail may change. Hopefully
not to much. Consider this some sort of RFC.

>From an application perspective there is two case, one is when you
absolutely don't care about asynchronous behavior and second one is
when you don't want to have your UI lock.

In case you don't care about asynchronous behavior, you would do :

obj = efl_add(EFL_CANVAS_IMAGE, canvas);
efl_uri_set(obj, "uri://somewhere/somefile", key);
efl_gfx_buffer_size(obj, , );
efl_gfx_fill_set(obj, 0, 0, w, h);
efl_gfx_visible_set(obj, 1);

Now in the case of an asynchronous file openning :

obj = efl_add(EFL_CANVAS_IMAGE, canvas);
future = efl_uri_set(obj, "uri://somewhere/somefile", key);
future = efl_future_then(future, &_efl_image_pixels_load,
&_efl_image_failed, &_efl_image_progress, obj);
efl_future_then(future, &_efl_image_show, &_efl_image_failed,
&_efl_image_progress, obj);

void
_efl_image_pixels_load(void *data, const Efl_Event *ev)
{
   Efl_Future_Event_Success *success = ev->info;
   Efl *obj = data;
   Eina_Rectangle *r = success->value;
   Efl_Future *f;

   efl_gfx_fill_set(obj, 0, 0, r->w, r->h);
   f = efl_gfx_image_load(obj);
   efl_future_chain(success->next, f); // This connect the resolution
of f with the next promise
}

void
_efl_image_show(void *data, const Efl_Event *ev EINA_UNUSED)
{
   Efl *obj = data;

   efl_gfx_visible_set(obj, 1);
}

void
_efl_image_progress(void *data, const Efl_Event *ev)
{
   Efl_Future_Event_Progress *progress = ev->info;
   Efl_Progress *progress = progress->progress;

   fprintf(stderr, "Step '%s' %i/%i: %f\n",
   progress->description,
   progress->step, progress->step_count,
   progress->percent);
}

void
_efl_image_failed(void *data, const Efl_Event *ev)
{
   Efl_Future_Event_Failure *failed = ev->info;

   fprintf(stderr, "Oops: '%s'\n", eina_error_msg_get(failed->error));
}

It is also to be noted that the first example will not work with
anything else than file (If you need to download something before
displaying it, you obviously need an asynchronous behavior). It won't
block, but it will also not display anything.

This example also show the problem with using eo event and their double cast.

I am not going to paste here the code of efl_ui_image.c which use our
current infrastructure to do the same as the few lines above in a more
verbose and tricky way.
-- 
Cedric BAIL

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/efl] master 02/02: elm fileselector: fix legacy methods for Entry and Button

[Vitor Sousa]

vitorsousa pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=35ecfcd65014b0d05f20f1c0a18c299cbebd7429

commit 35ecfcd65014b0d05f20f1c0a18c299cbebd7429
Author: Vitor Sousa 
Date:   Wed Sep 14 21:02:15 2016 -0300

elm fileselector: fix legacy methods for Entry and Button

Some legacy functions that works with string paths were not redirecting for
the correct code when called with Elm.Fileselector.Button or
Elm.Fileselector.Entry.
This commit fixes this problem.

@fix
---
 src/lib/elementary/elc_fileselector.c  | 52 ++
 src/lib/elementary/elc_fileselector_button.c   | 50 +++--
 src/lib/elementary/elc_fileselector_entry.c| 31 +
 src/lib/elementary/elm_interface_fileselector.h| 27 +++
 .../elementary/elm_widget_fileselector_button.h|  1 +
 5 files changed, 150 insertions(+), 11 deletions(-)

diff --git a/src/lib/elementary/elc_fileselector.c 
b/src/lib/elementary/elc_fileselector.c
index 1f87d75..cc3a065 100644
--- a/src/lib/elementary/elc_fileselector.c
+++ b/src/lib/elementary/elc_fileselector.c
@@ -2487,6 +2487,24 @@ EAPI const char *
 elm_fileselector_selected_get(const Evas_Object *obj)
 {
ELM_FILESELECTOR_INTERFACE_CHECK(obj, NULL);
+
+   const Efl_Class *cls = efl_class_get(obj);
+   if (cls == ELM_FILESELECTOR_CLASS)
+ return _elm_fileselector_selected_get_internal(obj);
+   else if (cls == ELM_FILESELECTOR_ENTRY_CLASS)
+ return _elm_fileselector_entry_selected_get_internal(obj);
+   else if (cls == ELM_FILESELECTOR_BUTTON_CLASS)
+ return _elm_fileselector_button_selected_get_internal(obj);
+   else
+ {
+ERR("Unknown Elm.Fileselector class");
+return NULL;
+ }
+}
+
+const char *
+_elm_fileselector_selected_get_internal(const Evas_Object *obj)
+{
ELM_FILESELECTOR_DATA_GET(obj, sd);
if (!sd->path) return NULL;
 
@@ -2517,6 +2535,25 @@ elm_fileselector_selected_set(Evas_Object *obj,
   const char *_path)
 {
ELM_FILESELECTOR_INTERFACE_CHECK(obj, EINA_FALSE);
+
+   const Efl_Class *cls = efl_class_get(obj);
+   if (cls == ELM_FILESELECTOR_CLASS)
+ return _elm_fileselector_selected_set_internal(obj, _path);
+   else if (cls == ELM_FILESELECTOR_ENTRY_CLASS)
+ return _elm_fileselector_entry_selected_set_internal(obj, _path);
+   else if (cls == ELM_FILESELECTOR_BUTTON_CLASS)
+ return _elm_fileselector_button_selected_set_internal(obj, _path);
+   else
+ {
+ERR("Unknown Elm.Fileselector class");
+return EINA_FALSE;
+ }
+}
+
+Eina_Bool
+_elm_fileselector_selected_set_internal(Evas_Object *obj, const char *_path)
+{
+   ELM_FILESELECTOR_INTERFACE_CHECK(obj, EINA_FALSE);
Eina_Bool ret = EINA_FALSE;
char *dir;
char *path;
@@ -2652,6 +2689,21 @@ EAPI const Eina_List *
 elm_fileselector_selected_paths_get(const Evas_Object* obj)
 {
ELM_FILESELECTOR_INTERFACE_CHECK(obj, NULL);
+
+   const Efl_Class *cls = efl_class_get(obj);
+   if (cls == ELM_FILESELECTOR_CLASS)
+ return _elm_fileselector_selected_paths_get_internal(obj);
+   else if (cls == ELM_FILESELECTOR_BUTTON_CLASS)
+ return _elm_fileselector_button_selected_paths_get_internal(obj);
+   else
+ ERR("Unknown Elm.Fileselector class");
+   return NULL;
+}
+
+const Eina_List *
+_elm_fileselector_selected_paths_get_internal(const Evas_Object* obj)
+{
+   ELM_FILESELECTOR_INTERFACE_CHECK(obj, NULL);
Eina_List *l;
Elm_Object_Item *item;
ELM_FILESELECTOR_DATA_GET(obj, sd);
diff --git a/src/lib/elementary/elc_fileselector_button.c 
b/src/lib/elementary/elc_fileselector_button.c
index 3e90749..e408e2d 100644
--- a/src/lib/elementary/elc_fileselector_button.c
+++ b/src/lib/elementary/elc_fileselector_button.c
@@ -239,6 +239,7 @@ _elm_fileselector_button_efl_canvas_group_group_del(Eo 
*obj, Elm_Fileselector_Bu
eina_stringshare_del(sd->fsd.path);
if (sd->fsd.selection)
  efl_unref(sd->fsd.selection);
+   eina_stringshare_del(sd->fsd.selection_path);
evas_object_del(sd->fsw);
 
efl_canvas_group_del(efl_super(obj, MY_CLASS));
@@ -334,7 +335,7 @@ EINA_DEPRECATED EAPI void
 elm_fileselector_button_path_set(Evas_Object *obj, const char *path)
 {
ELM_FILESELECTOR_INTERFACE_CHECK(obj);
-   _elm_fileselector_button_path_set_internal(obj, path);
+   elm_fileselector_path_set(obj, path);
 }
 
 EOLIAN static void
@@ -370,7 +371,7 @@ EINA_DEPRECATED EAPI const char *
 elm_fileselector_button_path_get(const Evas_Object *obj)
 {
ELM_FILESELECTOR_INTERFACE_CHECK(obj, NULL);
-   return _elm_fileselector_button_path_get_internal(obj);
+   return elm_fileselector_path_get(obj);
 }
 
 EOLIAN static Efl_Model *
@@ -514,6 +515,16 @@ 
_elm_fileselector_button_elm_interface_fileselector_multi_select_get(Eo *obj EIN
return sd->fsd.multi;
 }
 
+const Eina_List *
+_elm_fileselector_button_selected_paths_get_internal(const Evas_Object 

[EGIT] [core/efl] master 01/02: elm fileselector: fix test to wait for the right event

[Vitor Sousa]

vitorsousa pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=93d7b480fd390603b1d9f1b3779449d56c337fc1

commit 93d7b480fd390603b1d9f1b3779449d56c337fc1
Author: Vitor Sousa 
Date:   Wed Sep 14 20:45:16 2016 -0300

elm fileselector: fix test to wait for the right event

Fileselector test was waiting for the wrong event. It caused the test to
fail in some situations, since it could check the object when it is
not ready.

Fix T4502

@fix
---
 src/tests/elementary/elm_test_fileselector.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/src/tests/elementary/elm_test_fileselector.c 
b/src/tests/elementary/elm_test_fileselector.c
index 4a86d99..8800543 100644
--- a/src/tests/elementary/elm_test_fileselector.c
+++ b/src/tests/elementary/elm_test_fileselector.c
@@ -25,7 +25,7 @@ START_TEST (elm_atspi_role_get)
 END_TEST
 
 static void
-_directory_open_cb(void *data, Evas_Object *obj EINA_UNUSED, void *event_info 
EINA_UNUSED)
+_ready_cb(void *data, Evas_Object *obj EINA_UNUSED, void *event_info 
EINA_UNUSED)
 {
 Eina_Bool *ret = data;
 *ret = EINA_TRUE;
@@ -38,7 +38,7 @@ START_TEST (elm_fileselector_selected)
Eina_Stringshare *exist, *no_exist;
FILE *fp;
char *path;
-   Eina_Bool selected;
+   Eina_Bool open, selected;
 
elm_init(1, NULL);
 
@@ -60,13 +60,14 @@ START_TEST (elm_fileselector_selected)
win = elm_win_add(NULL, "fileselector", ELM_WIN_BASIC);
 
fileselector = elm_fileselector_add(win);
-   evas_object_smart_callback_add(fileselector, "directory,open", 
_directory_open_cb, );
+   evas_object_smart_callback_add(fileselector, "directory,open", _ready_cb, 
);
+   evas_object_smart_callback_add(fileselector, "selected", _ready_cb, 
);
 
ck_assert(!elm_fileselector_selected_set(fileselector, no_exist));
 
-   selected = EINA_FALSE;
+   open = EINA_FALSE;
ck_assert(elm_fileselector_selected_set(fileselector, path));
-   ck_assert(elm_test_helper_wait_flag(10, ));
+   ck_assert(elm_test_helper_wait_flag(10, ));
 
ck_assert_str_eq(elm_fileselector_selected_get(fileselector), path);
 

-- 

[EGIT] [core/efl] master 02/02: elementary: properly handle refcounting of file in efl_ui_image asynchronous image openning.

[Cedric BAIL]

cedric pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=351af26271f5a3fe4d5dd03fb2a8381e5f067400

commit 351af26271f5a3fe4d5dd03fb2a8381e5f067400
Author: Cedric Bail 
Date:   Wed Sep 14 16:52:08 2016 -0700

elementary: properly handle refcounting of file in efl_ui_image 
asynchronous image openning.
---
 src/lib/elementary/efl_ui_image.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/lib/elementary/efl_ui_image.c 
b/src/lib/elementary/efl_ui_image.c
index b1ddcc5..3a28ee4 100644
--- a/src/lib/elementary/efl_ui_image.c
+++ b/src/lib/elementary/efl_ui_image.c
@@ -254,7 +254,7 @@ _efl_ui_image_async_open_do(void *data, Ecore_Thread 
*thread)
 
if (ecore_thread_check(thread)) return;
 
-   if (todo->f_set) f = todo->f_set;
+   if (todo->f_set) f = eina_file_dup(todo->f_set);
else if (todo->file)
  {
 // blocking

-- 

[EGIT] [core/efl] master 01/02: eina: allow graceful failure when calling eina_thread_cancel with NULL.

[Cedric BAIL]

cedric pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=4d69f472fe31a9006436a05282a8376c7a712d41

commit 4d69f472fe31a9006436a05282a8376c7a712d41
Author: Cedric Bail 
Date:   Wed Sep 14 16:50:05 2016 -0700

eina: allow graceful failure when calling eina_thread_cancel with NULL.
---
 src/lib/eina/eina_thread.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/lib/eina/eina_thread.c b/src/lib/eina/eina_thread.c
index d40073a..5002a42 100644
--- a/src/lib/eina/eina_thread.c
+++ b/src/lib/eina/eina_thread.c
@@ -230,6 +230,7 @@ eina_thread_name_set(Eina_Thread t, const char *name)
 EAPI Eina_Bool
 eina_thread_cancel(Eina_Thread t)
 {
+   if (!t) return EINA_FALSE;
return pthread_cancel((pthread_t)t) == 0;
 }
 

-- 

Re: [E-devel] Pre-release tarballs for efl 1.18.1

[Jean Guyomarc'h]

Hi Stefan,

actually there is a big bug with osx semaphores that is still there.
It is a regression that I was almost sure was introduced after the
1.18 release, but it appears I was wrong, and it already landed in
1.18.
When building a lot (e.g. running plenty of edje_cc) nasty things
happen, edje_cc segfaults, everything goes wrong when evas cannot
create thread queues.
And when I tested the homebrew receipe with a self-packaged 1.18.1, of
course it did not show up then...

I am very sorry, but I think the release should be delayed by a day,
there are two more patches to backport to overcome this :/
- first one is 180b24f2a0dbf4476e1baf2fc535ebd422a5abce it does not
fix the problem entirely, but is required for the next patch which
actually solves everything;
- 5db3357f4029ad88b14ceb7b125d981e23889ec8 - which completely fixes the problem.
After applying these two patches to the sources you distributed, the
nasty bug died. Considering the advanced stage of the release, I
prefer to let you handle those.

Sorry for the trouble :/

Best regards,
Jean
Jean


On Wed, Sep 14, 2016 at 3:55 PM, Stefan Schmidt  wrote:
> Hello.
>
> I just uploaded the tarballs for 1.17.1 which is the first stable
> release of our 1.18.x branch.
>
> If I hear nothing problematic within the next 24 hours, I will do the
> final release.
>
> https://download.enlightenment.org/pre-releases/efl-1.18.1-pre.tar.gz
> 361ac885a31b7453b44b780c3662a0249f60914041ff1326629b63dffe4406db
>
> https://download.enlightenment.org/pre-releases/efl-1.18.1-pre.tar.xz
> d6a4242d3c8c75758c1d32054c8652d880e148109fb9a14550ef65bb87ae5842
>
> regards
> Stefan Schmidt
>
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [RFC] EFL Multi-seat

[Derek Foreman]

On 14/09/16 10:59 AM, Guilherme Íscaro wrote:
> Hey Christopher, some comments were answered by k-s. I will add some
> thoughts.
> 
> On Tue, Sep 13, 2016 at 8:15 PM, Christopher Michael > wrote:
> 
>> Hi Gustavo,
>>
>> Quite a few inlined comments below, so please read whole email :)
>>
>> On 09/13/2016 06:00 PM, Bruno Dilly wrote:
>>> Hi folks,
>>>
>>> We’re working on improve EFL to support multi-seat in the same
>> application
>>> window.
>>>
>>> For make it doable, we’re considering the following approaches:
>>>
>>>-
>>>
>>>When using Wayland (Weston compositor) just get seat information from
>> it
>>>-
>>>
>>
>> What about the Enlightenment wayland compositor ??
>>
>>>When using X11 or FB, use VNC server to gather multiple seats mapped
>> to
>>>remote clients
>>>
>>>
>>> To make it possible, the following changes on Evas, Ecore_Evas, Ecore and
>>> Ecore_Wl2 APIs are proposed. Please let us read your comments about it
>> =)
>>>
>>> After this work is done we’ll support it on Edje, but it’s not covered by
>>> this discussion (we’ll send another RFC if it seems required at the
>> time).
>>>
>>> Some tests and PoC were written on this repository:
>>>
>>> https://github.com/profusion/multi-seat-tests/
>>>
>>> Also could somebody please help us creating dev accounts for Iscaro and
>> me?
>>
>> Uhhh, you should already have a dev account...
>>
>>> So we could create dev branches and avoid keeping our work on external
>>> repositories and making our workflow a bit more straightforward?
>>>
>>> Thanks in advance
>>>
>>>
>>> = Changes on Evas =
>>>
>>>-
>>>
>>>_Evas_Public_Data should contain a hash indexed by seat of focused
>>>Evas_Objects. From “pd->focused” to “pd->focused[seat]”.
>>>-
>>>
>>>A function similar to evas_object_top_at_pointer_get(const Evas *e)
>>>should be added. This new function will receive the Efl_Input_Device
>> (the
>>>seat) as argument. The old function should return the top Evas_Object
>>>according to the default seat
>>>-
>>
>> I don't think using Efl_Input_Device as "the seat" is a good idea here.
>> A single seat can have multiple input devices (pointer, keyboard, etc).
>> Efl_Input_Device (to me) implies a single input device (ie: a single
>> pointer, single keyboard, etc). Whereas a "seat" can have multiple
>> devices attached...
>>
> 
> Well, we decided to use an Efl_Input_Device because it already exists a
> class that refers to a seat. In our idea every input (mouse, and keyboard)
> would have as parent the seat that it belongs to.
> 
> 
>>
>>>
>>>evas_canvas_focus_get() should return the object focused by the
>> default
>>>seat.
>>
>> IMO, this is not going to entirely work. In Wayland, you can have
>> "pointer focus", "keyboard focus", "touch focus", etc, etc ... a single
>> object focused by the "default" seat is not likely to cover everything.
>>
>> Pointer One on Seat One could be focused Object One, while Pointer Two
>> on Seat One could be focusing a different object but on the same canvas.
>> The function evas_canvas_focus_get should likely take some parameters
>> here...perhaps the seat ? Perhaps the pointer ? Not 100% sure, just
>> tossing out thoughts...
>>
> 
> In this case where someone has two mices (for example) in the same seat,
> why not consider that the user just changed the focus from object one to
> object two ?

Before taking me too seriously, please understand that I know more about
wayland than EFL, and don't really follow X details and what-not...
Sorry if I'm repeating things people already know.

Under wayland each seat can only have one "pointer", one "keyboard" and
one "touch" object.

The pointer for seat "One" will be moved by all the mice in seat "One"
as if they were a single device.  So the problem we're discussing here
simply can't happen.  The seat can have 1000 mice but it can only ever
have one pointer (and thus one pointer focus)  Seat "Two"'s pointer can,
of course, focus something else entirely, or the same thing seat "One"'s
pointer is focusing.

Similarly, two keyboards in the same seat act as a single keyboard (the
important bit here is that all their modifiers are combined, as is their
map of down keys - banging on the "a" key on keyboard two while it's
held down on keyboard one will do nothing at all).

Wayland does have separate focus for pointer, keyboard, and touch within
a seat - and there's no "seat focus" at all.

Thanks for listening to my rambling, really nice to see this progressing!

Derek


> 
>>
>>>-
>>>
>>>evas_canvas_pointer_canvas_xy_get() Should return the XY from the
>>>default seat.
>>>-
>>>
>>>evas_canvas_seat_pointer_canvas_xy_get() - Same thing as
>>>evas_canvas_pointer_canvas_xy_get(), however it returns the XY based
>> on the
>>>seat.
>>>-
>>>
>>>evas_object_focus_set() - Will set/unset the focus only for the
>> default
>>>seat.
>>>-
>>>
>>>evas_object_focus_by_seat_set() 

Re: [E-devel] [RFC] EFL Multi-seat

[Guilherme Íscaro]

On Tue, Sep 13, 2016 at 8:17 PM, Cedric BAIL  wrote:

> Hello,
>
> On Tue, Sep 13, 2016 at 3:00 PM, Bruno Dilly 
> wrote:
> > We’re working on improve EFL to support multi-seat in the same
> application
> > window.
>
> For people who do not know what multi-seat means in this context, we
> are talking about allowing multiple set of keyboard/mouse grouped into
> seat behave independently in the same application. There is no toolkit
> that support this at the moment, but Wayland/Weston does as you can
> see in this video: https://www.youtube.com/watch?v=WO2L_ihO_rI . This
> has nothing to do with systemd/logind multi seat, which actually
> account to a group of screen/keyboard/mouse per user just sharing the
> same CPU (like an hold X terminal on a mainframe).
>
> > For make it doable, we’re considering the following approaches:
> >
> >-
> >
> >When using Wayland (Weston compositor) just get seat information from
> it
> >-
> >
> >When using X11 or FB, use VNC server to gather multiple seats mapped
> to
> >remote clients
> >
> >
> > To make it possible, the following changes on Evas, Ecore_Evas, Ecore and
> > Ecore_Wl2 APIs are proposed. Please let us read your comments about it
> =)
> >
> > After this work is done we’ll support it on Edje, but it’s not covered by
> > this discussion (we’ll send another RFC if it seems required at the
> time).
> >
> > Some tests and PoC were written on this repository:
> >
> > https://github.com/profusion/multi-seat-tests/
> >
> > Also could somebody please help us creating dev accounts for Iscaro and
> me?
> > So we could create dev branches and avoid keeping our work on external
> > repositories and making our workflow a bit more straightforward?
>
> Sure, we have the probie status for that purpose. With the large work
> to be done here, I don't think there is any problem to let you become
> probies. Please send me your info.txt properly filled and a ssh public
> keys. I will wait for a week before pushing it to let a chance to
> everyone to complain here if they feel like it is not motivated.
>
> > Thanks in advance
> >
> > = Changes on Evas =
> >
> >-
> >
> >_Evas_Public_Data should contain a hash indexed by seat of focused
> >Evas_Objects. From “pd->focused” to “pd->focused[seat]”.
>
> Wouldn't it make sense to actually just give internally a number to
> each seat and use this as a mapping ? This way instead of a hash, you
> would have an array, which is nicer for just holding a pointer I
> think. Also I don't see anywhere in your proposal any event to notify
> the registration/unregistration of a seat. This will be necessary in
> the future for handling for example focus in elementary. There is an
> EFL_CANVAS_EVENT_DEVICE_CHANGED, but I don't think it match the use
> case. Would an EFL_CANVAS_EVENT_DEVICE_ADD and
> EFL_CANVAS_EVENT_DEVICE_DEL make sense to everyone ? Speaking of event
> you have also not talked about the focus event (object and canvas).
>

About the events - In Ecore_Wl2 section we said that after a
wl_keyboard/wl_seat is added we would generate an ecore_event for that
notifying that a new device is available. This event_info will be the
Efl_Input_Device itself. Is this ok? We can do the same thing for focus,
inform the object + seat + device itself.


> >-
> >
> >A function similar to evas_object_top_at_pointer_get(const Evas *e)
> >should be added. This new function will receive the Efl_Input_Device
> (the
> >seat) as argument. The old function should return the top Evas_Object
> >according to the default seat
>
> For what purpose ?
>

Just wanted to keep the API sane. Should we ignore this one?


>
> >-
> >
> >evas_canvas_focus_get() should return the object focused by the
> default
> >seat.
> >-
> >
> >evas_canvas_pointer_canvas_xy_get() Should return the XY from the
> >default seat.
> >-
> >
> >evas_canvas_seat_pointer_canvas_xy_get() - Same thing as
> >evas_canvas_pointer_canvas_xy_get(), however it returns the XY based
> on the
> >seat.
>
> It will be nice in code to refactor evas_canvas_pointer_canvas_xy_get
> to reuse evas_canvas_seat_pointer_canvas_xy_get. Also at this stage, I
> think none of the multi seat function should be part of the legacy API
> and the efl/eo interface should all be multi seat by default (If you
> pass NULL as a device, I think it should target the default seat).
>

Indeed, our idea was to implement refactor the old functions to use new
seat functions passing the default seat as argument.


>
> >-
> >
> >evas_object_focus_set() - Will set/unset the focus only for the
> default
> >seat.
> >-
> >
> >evas_object_focus_by_seat_set() should be added
>
> Same as above.
>
> >-
> >
> >evas_event_feed_hold - Will act in the default seat
> >-
> >
> >Add evas_event_feed_hold_by_seat() - Should we support this ?
> >-
> >
> >Add 

Re: [E-devel] Schedule discussion for 1.19

[Tom Hacohen]

On 14/09/16 17:53, Cedric BAIL wrote:
> On Wed, Sep 14, 2016 at 3:03 AM, Tom Hacohen  wrote:
>> On 13/09/16 23:07, Stefan Schmidt wrote:
>>> On 12/09/16 19:01, Cedric BAIL wrote:
 On Mon, Sep 12, 2016 at 7:58 AM, Stefan Schmidt  
 wrote:
> On 10/09/16 01:29, Cedric BAIL wrote:
>> I fully agree with Andrew. I have yet to review what still need to be
>> done regarding Efl new interface task, but I hope that 1.19 will be
>> our final call. We do now have time to cleanup example and check that
>> things look fine.
>
> Please correct me if I did not get you two correctly here.
>
> You both think we should release 1.19 only once the interface work is
> fully done? Be it in 3 months or in a year?

 I hope that we will be done by November.
>>>
>>> Hope dies last. :)
>>>
>>> More seriously. I have a hard time seeing that interfaces is fully done
>>> in November when we still argue promises (as a very basic part) again.
>>
>>  From what I remember, we decided promises will not take a key part in
>> this. We will not rely on promises at this point.
>
> It was requested to have an eo based promise to make decision. Also it
> was stated in that thread that there will not be any async request API
> (like file_set should be) if we do not have promise. This also include
> no MVC (We are not going back to insane complexity of handling it with
> events and having to maintain another insane hydra).
>

This is not true. It was requested to move them to Eo *and* it was also 
stated we should start slow and use them in only a few APIs to see how 
they are, and not rely on them in all of the EFL.

--
Tom.

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Schedule discussion for 1.19

[Cedric BAIL]

On Wed, Sep 14, 2016 at 3:03 AM, Tom Hacohen  wrote:
> On 13/09/16 23:07, Stefan Schmidt wrote:
>> On 12/09/16 19:01, Cedric BAIL wrote:
>>> On Mon, Sep 12, 2016 at 7:58 AM, Stefan Schmidt  
>>> wrote:
 On 10/09/16 01:29, Cedric BAIL wrote:
> I fully agree with Andrew. I have yet to review what still need to be
> done regarding Efl new interface task, but I hope that 1.19 will be
> our final call. We do now have time to cleanup example and check that
> things look fine.

 Please correct me if I did not get you two correctly here.

 You both think we should release 1.19 only once the interface work is
 fully done? Be it in 3 months or in a year?
>>>
>>> I hope that we will be done by November.
>>
>> Hope dies last. :)
>>
>> More seriously. I have a hard time seeing that interfaces is fully done
>> in November when we still argue promises (as a very basic part) again.
>
>  From what I remember, we decided promises will not take a key part in
> this. We will not rely on promises at this point.

It was requested to have an eo based promise to make decision. Also it
was stated in that thread that there will not be any async request API
(like file_set should be) if we do not have promise. This also include
no MVC (We are not going back to insane complexity of handling it with
events and having to maintain another insane hydra).
-- 
Cedric BAIL

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [RFC] EFL Multi-seat

[Christopher Michael]

On 09/14/2016 11:59 AM, Guilherme Íscaro wrote:
> Hey Christopher, some comments were answered by k-s. I will add some
> thoughts.
>
> On Tue, Sep 13, 2016 at 8:15 PM, Christopher Michael > wrote:
>
>> Hi Gustavo,
>>
>> Quite a few inlined comments below, so please read whole email :)
>>
>> On 09/13/2016 06:00 PM, Bruno Dilly wrote:
>>> Hi folks,
>>>
>>> We’re working on improve EFL to support multi-seat in the same
>> application
>>> window.
>>>
>>> For make it doable, we’re considering the following approaches:
>>>
>>>-
>>>
>>>When using Wayland (Weston compositor) just get seat information from
>> it
>>>-
>>>
>>
>> What about the Enlightenment wayland compositor ??
>>
>>>When using X11 or FB, use VNC server to gather multiple seats mapped
>> to
>>>remote clients
>>>
>>>
>>> To make it possible, the following changes on Evas, Ecore_Evas, Ecore and
>>> Ecore_Wl2 APIs are proposed. Please let us read your comments about it
>> =)
>>>
>>> After this work is done we’ll support it on Edje, but it’s not covered by
>>> this discussion (we’ll send another RFC if it seems required at the
>> time).
>>>
>>> Some tests and PoC were written on this repository:
>>>
>>> https://github.com/profusion/multi-seat-tests/
>>>
>>> Also could somebody please help us creating dev accounts for Iscaro and
>> me?
>>
>> Uhhh, you should already have a dev account...
>>
>>> So we could create dev branches and avoid keeping our work on external
>>> repositories and making our workflow a bit more straightforward?
>>>
>>> Thanks in advance
>>>
>>>
>>> = Changes on Evas =
>>>
>>>-
>>>
>>>_Evas_Public_Data should contain a hash indexed by seat of focused
>>>Evas_Objects. From “pd->focused” to “pd->focused[seat]”.
>>>-
>>>
>>>A function similar to evas_object_top_at_pointer_get(const Evas *e)
>>>should be added. This new function will receive the Efl_Input_Device
>> (the
>>>seat) as argument. The old function should return the top Evas_Object
>>>according to the default seat
>>>-
>>
>> I don't think using Efl_Input_Device as "the seat" is a good idea here.
>> A single seat can have multiple input devices (pointer, keyboard, etc).
>> Efl_Input_Device (to me) implies a single input device (ie: a single
>> pointer, single keyboard, etc). Whereas a "seat" can have multiple
>> devices attached...
>>
>
> Well, we decided to use an Efl_Input_Device because it already exists a
> class that refers to a seat. In our idea every input (mouse, and keyboard)
> would have as parent the seat that it belongs to.
>
>
>>
>>>
>>>evas_canvas_focus_get() should return the object focused by the
>> default
>>>seat.
>>
>> IMO, this is not going to entirely work. In Wayland, you can have
>> "pointer focus", "keyboard focus", "touch focus", etc, etc ... a single
>> object focused by the "default" seat is not likely to cover everything.
>>
>> Pointer One on Seat One could be focused Object One, while Pointer Two
>> on Seat One could be focusing a different object but on the same canvas.
>> The function evas_canvas_focus_get should likely take some parameters
>> here...perhaps the seat ? Perhaps the pointer ? Not 100% sure, just
>> tossing out thoughts...
>>
>
> In this case where someone has two mices (for example) in the same seat,
> why not consider that the user just changed the focus from object one to
> object two ?
>

You can ignore my comments wrt this. I was thinking of multiseat along 
the lines of the systemd/logind type of multiseat.

>
>>
>>>-
>>>
>>>evas_canvas_pointer_canvas_xy_get() Should return the XY from the
>>>default seat.
>>>-
>>>
>>>evas_canvas_seat_pointer_canvas_xy_get() - Same thing as
>>>evas_canvas_pointer_canvas_xy_get(), however it returns the XY based
>> on the
>>>seat.
>>>-
>>>
>>>evas_object_focus_set() - Will set/unset the focus only for the
>> default
>>>seat.
>>>-
>>>
>>>evas_object_focus_by_seat_set() should be added
>>>-
>>>
>>>evas_event_feed_hold - Will act in the default seat
>>>-
>>>
>>
>> Likely all these above functions should take a "seat" as a parameter ...
>> Everything above is "coded" using the default seat ... What happens with
>> other seats ???
>>
>>>Add evas_event_feed_hold_by_seat() - Should we support this ?
>>
>> Probably, yes...
>>
>>>-
>>>
>>>Add evas_device_seat_get(Evas_Device *dev);
>>>-
>>>
>>>   We may create a helper function in Efl_Input_Device::seat_get
>>>   -
>>>
>>>All evas_event_* functions will work on the top most seat.
>>
>> I think you may run into a problem in the future with this ... Have not
>> thought it out entirely, but (imo) limiting functions to a single "top
>> most" seat is likely to lead to problems in the future where there are
>> multiple seats... ie: What about events coming from other seats ??
>>
>> So in order
>>>to add an event for ‘seat 1’ one should do: evas_device_push(evas,
>>>seatOne); 

Re: [E-devel] [RFC] EFL Multi-seat

[Guilherme Íscaro]

Hey Christopher, some comments were answered by k-s. I will add some
thoughts.

On Tue, Sep 13, 2016 at 8:15 PM, Christopher Michael  wrote:

> Hi Gustavo,
>
> Quite a few inlined comments below, so please read whole email :)
>
> On 09/13/2016 06:00 PM, Bruno Dilly wrote:
> > Hi folks,
> >
> > We’re working on improve EFL to support multi-seat in the same
> application
> > window.
> >
> > For make it doable, we’re considering the following approaches:
> >
> >-
> >
> >When using Wayland (Weston compositor) just get seat information from
> it
> >-
> >
>
> What about the Enlightenment wayland compositor ??
>
> >When using X11 or FB, use VNC server to gather multiple seats mapped
> to
> >remote clients
> >
> >
> > To make it possible, the following changes on Evas, Ecore_Evas, Ecore and
> > Ecore_Wl2 APIs are proposed. Please let us read your comments about it
> =)
> >
> > After this work is done we’ll support it on Edje, but it’s not covered by
> > this discussion (we’ll send another RFC if it seems required at the
> time).
> >
> > Some tests and PoC were written on this repository:
> >
> > https://github.com/profusion/multi-seat-tests/
> >
> > Also could somebody please help us creating dev accounts for Iscaro and
> me?
>
> Uhhh, you should already have a dev account...
>
> > So we could create dev branches and avoid keeping our work on external
> > repositories and making our workflow a bit more straightforward?
> >
> > Thanks in advance
> >
> >
> > = Changes on Evas =
> >
> >-
> >
> >_Evas_Public_Data should contain a hash indexed by seat of focused
> >Evas_Objects. From “pd->focused” to “pd->focused[seat]”.
> >-
> >
> >A function similar to evas_object_top_at_pointer_get(const Evas *e)
> >should be added. This new function will receive the Efl_Input_Device
> (the
> >seat) as argument. The old function should return the top Evas_Object
> >according to the default seat
> >-
>
> I don't think using Efl_Input_Device as "the seat" is a good idea here.
> A single seat can have multiple input devices (pointer, keyboard, etc).
> Efl_Input_Device (to me) implies a single input device (ie: a single
> pointer, single keyboard, etc). Whereas a "seat" can have multiple
> devices attached...
>

Well, we decided to use an Efl_Input_Device because it already exists a
class that refers to a seat. In our idea every input (mouse, and keyboard)
would have as parent the seat that it belongs to.


>
> >
> >evas_canvas_focus_get() should return the object focused by the
> default
> >seat.
>
> IMO, this is not going to entirely work. In Wayland, you can have
> "pointer focus", "keyboard focus", "touch focus", etc, etc ... a single
> object focused by the "default" seat is not likely to cover everything.
>
> Pointer One on Seat One could be focused Object One, while Pointer Two
> on Seat One could be focusing a different object but on the same canvas.
> The function evas_canvas_focus_get should likely take some parameters
> here...perhaps the seat ? Perhaps the pointer ? Not 100% sure, just
> tossing out thoughts...
>

In this case where someone has two mices (for example) in the same seat,
why not consider that the user just changed the focus from object one to
object two ?


>
> >-
> >
> >evas_canvas_pointer_canvas_xy_get() Should return the XY from the
> >default seat.
> >-
> >
> >evas_canvas_seat_pointer_canvas_xy_get() - Same thing as
> >evas_canvas_pointer_canvas_xy_get(), however it returns the XY based
> on the
> >seat.
> >-
> >
> >evas_object_focus_set() - Will set/unset the focus only for the
> default
> >seat.
> >-
> >
> >evas_object_focus_by_seat_set() should be added
> >-
> >
> >evas_event_feed_hold - Will act in the default seat
> >-
> >
>
> Likely all these above functions should take a "seat" as a parameter ...
> Everything above is "coded" using the default seat ... What happens with
> other seats ???
>
> >Add evas_event_feed_hold_by_seat() - Should we support this ?
>
> Probably, yes...
>
> >-
> >
> >Add evas_device_seat_get(Evas_Device *dev);
> >-
> >
> >   We may create a helper function in Efl_Input_Device::seat_get
> >   -
> >
> >All evas_event_* functions will work on the top most seat.
>
> I think you may run into a problem in the future with this ... Have not
> thought it out entirely, but (imo) limiting functions to a single "top
> most" seat is likely to lead to problems in the future where there are
> multiple seats... ie: What about events coming from other seats ??
>
> So in order
> >to add an event for ‘seat 1’ one should do: evas_device_push(evas,
> >seatOne); evas_event_*(); evas_device_pop(evas);
> >-
> >
> >Evas will automatically create Evas_Devices
> >
> >
> >
> > = Changes on Ecore_Evas =
> >
> >-
> >
> >ecore_evas_x11_vnc_server_enabled(Ecore_Evas *ee, bool enable); ->
> This
> >will 

[EGIT] [core/efl] master 01/01: bindings: cxx: add more new files to buildsystem to make sure they land in dist

[Stefan Schmidt]

stefan pushed a commit to branch master.

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

commit de8ac30d1a4b87d91274650c6a856e10e874cc2e
Author: Stefan Schmidt 
Date:   Wed Sep 14 18:01:25 2016 +0200

bindings: cxx: add more new files to buildsystem to make sure they land in 
dist

Another set of new files which have not been referenced and thus never put 
into
dist.
---
 src/Makefile_Cxx.am | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/Makefile_Cxx.am b/src/Makefile_Cxx.am
index 7b34c24..442d4fd 100644
--- a/src/Makefile_Cxx.am
+++ b/src/Makefile_Cxx.am
@@ -13,7 +13,9 @@ bindings/cxx/eo_cxx/Eo.hh \
 bindings/cxx/eo_cxx/eo_init.hh \
 bindings/cxx/eo_cxx/eo_ops.hh \
 bindings/cxx/eo_cxx/eo_wref.hh \
+bindings/cxx/eo_cxx/eo_future.hh \
 bindings/cxx/eo_cxx/eo_promise.hh \
+bindings/cxx/eo_cxx/eo_promise_meta.hh \
 bindings/cxx/eo_cxx/eo_private.hh
 
 ### Elementary C++
@@ -171,6 +173,7 @@ bindings/cxx/eina_cxx/eina_type_traits.hh \
 bindings/cxx/eina_cxx/eina_value.hh \
 bindings/cxx/eina_cxx/eina_workarounds.hh \
 bindings/cxx/eina_cxx/eina_copy_traits.hh \
+bindings/cxx/eina_cxx/eina_variant.hh \
 bindings/cxx/eina_cxx/Eina.hh
 
 ### Eio

-- 

[EGIT] [apps/epour] master 01/02: Theme: Use custom style name and remove call to extension_add

[Kai Huuhko]

kuuko pushed a commit to branch master.

http://git.enlightenment.org/apps/epour.git/commit/?id=dd72a3f2a10f473060f444a96acd07cb0a6e3afb

commit dd72a3f2a10f473060f444a96acd07cb0a6e3afb
Author: Kai Huuhko 
Date:   Tue Sep 13 13:49:18 2016 +0300

Theme: Use custom style name and remove call to extension_add
---
 epour/gui/__init__.py   | 3 +--
 themes/default/main.edc | 8 
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/epour/gui/__init__.py b/epour/gui/__init__.py
index 5d38d7c..b94c053 100644
--- a/epour/gui/__init__.py
+++ b/epour/gui/__init__.py
@@ -80,13 +80,12 @@ class MainInterface(object):
 
 def __init__(self, parent, session):
 self._session = session
-self.itc = TorrentClass(self._session, "double_label")
+self.itc = TorrentClass(self._session, "torrent")
 
 self.torrentitems = {}
 
 theme = Theme.default_get()
 theme.overlay_add(theme_file)
-theme.extension_add(theme_file)
 
 win = self.win = Window(
 "epour", ELM_WIN_BASIC, size=(480 * scale, 400 * scale),
diff --git a/themes/default/main.edc b/themes/default/main.edc
index aca4c04..571043b 100644
--- a/themes/default/main.edc
+++ b/themes/default/main.edc
@@ -718,7 +718,7 @@ collections {
 #define TREEPAD 19
 
 
-   group { "elm/genlist/item/double_label/default"; nomouse;
+   group { "elm/genlist/item/torrent/default"; nomouse;
   data.item: "selectraise" "on";
   data.item: "focusraise" "on";
   data.item: "texts" "elm.text elm.text.sub";
@@ -1025,9 +1025,9 @@ collections {
   }
   inherit: "genlist_top";
}
-   ODD("elm/genlist/item_odd/double_label/default", 
"elm/genlist/item/double_label/default")
-   COMPRESS_SUB("elm/genlist/item_compress/double_label/default", 
"elm/genlist/item/double_label/default")
-   COMPRESS_SUB_ODD("elm/genlist/item_compress_odd/double_label/default", 
"elm/genlist/item/double_label/default")
+   ODD("elm/genlist/item_odd/torrent/default", 
"elm/genlist/item/torrent/default")
+   COMPRESS_SUB("elm/genlist/item_compress/torrent/default", 
"elm/genlist/item/torrent/default")
+   COMPRESS_SUB_ODD("elm/genlist/item_compress_odd/torrent/default", 
"elm/genlist/item/torrent/default")
 
 }
 

-- 

[EGIT] [apps/epour] master 02/02: Fix progressbar updates

[Kai Huuhko]

kuuko pushed a commit to branch master.

http://git.enlightenment.org/apps/epour.git/commit/?id=09440577a04cabedeca1792f72d3ed0364dae720

commit 09440577a04cabedeca1792f72d3ed0364dae720
Author: Kai Huuhko 
Date:   Wed Sep 14 18:30:37 2016 +0300

Fix progressbar updates
---
 epour/gui/__init__.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/epour/gui/__init__.py b/epour/gui/__init__.py
index b94c053..e14532c 100644
--- a/epour/gui/__init__.py
+++ b/epour/gui/__init__.py
@@ -263,6 +263,9 @@ class MainInterface(object):
 self.torrentitems[info_hash].fields_update(
 "*", ELM_GENLIST_ITEM_FIELD_TEXT
 )
+self.torrentitems[info_hash].fields_update(
+"elm.swallow.progress", ELM_GENLIST_ITEM_FIELD_CONTENT
+)
 
 session.alert_manager.callback_add(
 "state_update_alert", state_update_alert_cb)

-- 

[EGIT] [core/enlightenment] master 01/01: move 'unmaximize' smart callback to after geom calc in client_unmaximize

[Mike Blumenkrantz]

discomfitor pushed a commit to branch master.

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

commit c29157189f9e493a7a9b16739147ca22dced80d5
Author: Mike Blumenkrantz 
Date:   Wed Sep 14 10:28:38 2016 -0400

move 'unmaximize' smart callback to after geom calc in client_unmaximize

fixes some cases where geometry wouldn't be accurately calculated, such as 
when
fullscreening a flash video in a browser
---
 src/bin/e_client.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/bin/e_client.c b/src/bin/e_client.c
index 0255ccb..20d18ac 100644
--- a/src/bin/e_client.c
+++ b/src/bin/e_client.c
@@ -3982,7 +3982,6 @@ e_client_unmaximize(E_Client *ec, E_Maximize max)
}
  if (e_config->window_maximize_animate && 
(!ec->maximize_anims_disabled))
ec->maximize_override = 1;
- evas_object_smart_callback_call(ec->frame, "unmaximize", NULL);
  e_client_resize_limit(ec, , );
  if (ec->saved.frame &&
(e_comp_object_frame_exists(ec->frame) || 
(!e_comp_object_frame_allowed(ec->frame
@@ -3990,6 +3989,7 @@ e_client_unmaximize(E_Client *ec, E_Maximize max)
   e_comp_object_frame_xy_adjust(ec->frame, x, y, , );
   e_comp_object_frame_wh_adjust(ec->frame, w, h, , );
}
+ evas_object_smart_callback_call(ec->frame, "unmaximize", NULL);
  if (!_e_client_maximize_run(ec, x, y, w, h))
ec->maximize_override = 0;
  if (vert)

-- 

Re: [E-devel] [RFC] EFL Multi-seat

[Bruno Dilly]

Hi Cedric,

On Tue, Sep 13, 2016 at 8:17 PM, Cedric BAIL  wrote:

> Hello,
>
> On Tue, Sep 13, 2016 at 3:00 PM, Bruno Dilly 
> wrote:
> > We’re working on improve EFL to support multi-seat in the same
> application
> > window.
>

[...]


> >
> > Also could somebody please help us creating dev accounts for Iscaro and
> me?
> > So we could create dev branches and avoid keeping our work on external
> > repositories and making our workflow a bit more straightforward?
>
> Sure, we have the probie status for that purpose. With the large work
> to be done here, I don't think there is any problem to let you become
> probies. Please send me your info.txt properly filled and a ssh public
> keys. I will wait for a week before pushing it to let a chance to
> everyone to complain here if they feel like it is not motivated.
>
>
Mine in on devs/inactive/bdilly.
All data is still updated (weird, right?), including the public key.

Iscaro is going to send you his info soon.

Thanks

Also thank you and devilhorns for the comments.
We'll wait a bit for more comments and we'll send a new version of the RFC
taking everything on consideration.

Regards

[...]


-- 
Bruno Dilly
ProFUSION embedded systems
http://profusion.mobi
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Pre-release tarballs for efl 1.18.1

[Stefan Schmidt]

Hello.

I just uploaded the tarballs for 1.17.1 which is the first stable 
release of our 1.18.x branch.

If I hear nothing problematic within the next 24 hours, I will do the 
final release.

https://download.enlightenment.org/pre-releases/efl-1.18.1-pre.tar.gz
361ac885a31b7453b44b780c3662a0249f60914041ff1326629b63dffe4406db

https://download.enlightenment.org/pre-releases/efl-1.18.1-pre.tar.xz
d6a4242d3c8c75758c1d32054c8652d880e148109fb9a14550ef65bb87ae5842

regards
Stefan Schmidt

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/efl] efl-1.18 01/01: release: Update NEWS and bump version for 1.18.1 release

[Stefan Schmidt]

stefan pushed a commit to branch efl-1.18.

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

commit beec7af1a39b9a1f280a83515af53632ba158ef4
Author: Stefan Schmidt 
Date:   Wed Sep 14 13:11:50 2016 +0200

release: Update NEWS and bump version for 1.18.1 release
---
 NEWS | 16 +++-
 configure.ac |  2 +-
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index bd43eaf..1d57c67 100644
--- a/NEWS
+++ b/NEWS
@@ -1,7 +1,21 @@
 ==
-EFL 1.18.0
+EFL 1.18.1
 ==
 
+Changes since 1.18.0:
+-
+
+Fixes:
+
+   * doc: put shot.sh into dist to allow make doc run from tarball
+   * examples: evas: ensure filter example lua files land in tarball
+   * elm: Install elm test images in the right place
+   * FDO icon theme: correct Inherits value
+   * edje - fix missing vector field frees, copies, handling etc.
+   * FDO icons: correctly list the intl icons in theme description file
+   * Fix elementary build when xkbcommon is in a non standard location (T4413)
+   * ecore_audio: fix distribution of eolian files
+
 Changes since 1.17.0:
 -
 
diff --git a/configure.ac b/configure.ac
index 102c90a..84b6542 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,4 +1,4 @@
-EFL_VERSION([1], [18], [0], [release])
+EFL_VERSION([1], [18], [1], [release])
 AC_INIT([efl], [efl_version], [enlightenment-devel@lists.sourceforge.net])
 
 AC_PREREQ([2.60])

-- 

Re: [E-devel] Schedule discussion for 1.19

[Simon Lees]

On 09/14/2016 07:37 AM, Stefan Schmidt wrote:
> Hello.
> 
> On 12/09/16 19:01, Cedric BAIL wrote:
>> On Mon, Sep 12, 2016 at 7:58 AM, Stefan Schmidt  
>> wrote:
>>> Hello.
>>>
>>> On 10/09/16 01:29, Cedric BAIL wrote:
 Hello,

 I fully agree with Andrew. I have yet to review what still need to be
 done regarding Efl new interface task, but I hope that 1.19 will be
 our final call. We do now have time to cleanup example and check that
 things look fine.
>>>
>>> Please correct me if I did not get you two correctly here.
>>>
>>> You both think we should release 1.19 only once the interface work is
>>> fully done? Be it in 3 months or in a year?
>>
>> I hope that we will be done by November.
> 
> 
> Hope dies last. :)
> 
> More seriously. I have a hard time seeing that interfaces is fully done 
> in November when we still argue promises (as a very basic part) again.
> 
> The feedback I got so far is: make it a feature based release and only 
> release it when interfaces as a showstopper bug is done.
> 
> I have my doubts this will fly, but if nobody else thinks this idea will 
> not work I stash my concerns and will see how I call help processing 
> this release. Just never ask me when this release will happen or point 
> out that distro or product schedules might need it done before XX :)
> 

As long as its sometime before September 2017 it works for my distro :-P
mind you the current definition of a LTS release is one that works for
my distro.

-- 

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

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



signature.asc
Description: OpenPGP digital signature
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL packaging on Debian

[Simon Lees]

On 09/14/2016 08:37 AM, Stefan Schmidt wrote:
> Hello.
> 
> On 14/09/16 00:13, Ross Vandegrift wrote:
>> On 09/13/2016 05:58 PM, Stefan Schmidt wrote:
>>> I guess you would need to ask the Debian packagers to update or find new
>>> ones wanting to keep up with the work. To me the maintainers seem to be
>>> missing in action and so far everybody stepped up to replace them. Part
>>> of the problem is that interested folks might not be a Debian
>>> maintainers and would need a sponsor. I tried to arrange for this with a
>>> Debian Developer I knew but even for the sponsor its a lot work so it
>>> did not pan out.
>>
>> The current Debian maintainer has been missing, but supposedly returning
>> soon.
> 
> Soon as in this year?
> 
> In the meantime, I've been maintaining updated Debian packaging
>> in the debian/sid branch of:
>>   https://github.com/rvandegrift/efl
>>   https://github.com/rvandegrift/e
>>
>> Soon, I hope we'll be able to get these into the archive.
> 
> I have seen you mention this before and I wonder how realistic this hope 
> is. Are you a Debian Developer or maintainer? Do you have a sponsor that 
> would sponsor your non packager uploads?
> 
> This all sounds hard, but over the last 3 years I have seen various 
> approaches to make the situation better. None of it succeeded.
> 
>>> If you compare this to other mainstream distros like OpenSUSE or Fedora
>>> which ship really up to date packages I can't really see why our code is
>>> not interesting for debian while it is for other distros. But given how
>>> long we have this situation I think we might have to face it that this
>>> will not change.
>>
>> Hypothesis: E17 on EFL 1.8 might be old, but it's reasonably stable and
>> useful.  So end-users that do not follow EFL development might not
>> know/care about new features.  Those that do probably build from source.
> 
> You think these users do also not care about bug fixes and security 
> fixes? You know many people that are using efl 1.8 and e17 and are happy 
> that Debian does not update to newer versions?
> 
> I find it hard to believe that keeping this versions comes from 
> something else but missing interest or motivation to update the 
> packages. I talk about Debian unstable here and not some years old 
> release. (I have been using Debian SID myself for over 10 years and at 
> that point packages have been updated when new versions came out)
> 
> regards
> Stefan Schmidt

The main problem is that if there's know one within debian doing the
work then the work doesn't get done, and were we to raise a major
security issue and know one is available to do the work or if the
package stops building and know one fixes it, its likely the packages
will just get dropped.

The other thing is that debian has lots of process and picking up debian
packaging isn't simple and easy as has been alluded to I think the only
really decent solution is hunting down a couple of debian devs and
convincing them  that they really want to use enlightenment all the time
once thats done they can do a little of the work and sponsor / help
people like Ross to do the majority of it. Unfortunately this is the
downside to debians development model (the upside being that what gets
packaged is done to a really high standard).

Its great that people like Ross are trying to push this forward so keep
up the good work and if there's anything someone also outside of debian
can help with or you have questions regarding configure flags etc let us
know and we will be happy to help.

Cheers

-- 

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

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



signature.asc
Description: OpenPGP digital signature
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Schedule discussion for 1.19

[Tom Hacohen]

On 13/09/16 23:07, Stefan Schmidt wrote:
> Hello.
>
> On 12/09/16 19:01, Cedric BAIL wrote:
>> On Mon, Sep 12, 2016 at 7:58 AM, Stefan Schmidt  
>> wrote:
>>> Hello.
>>>
>>> On 10/09/16 01:29, Cedric BAIL wrote:
 Hello,

 I fully agree with Andrew. I have yet to review what still need to be
 done regarding Efl new interface task, but I hope that 1.19 will be
 our final call. We do now have time to cleanup example and check that
 things look fine.
>>>
>>> Please correct me if I did not get you two correctly here.
>>>
>>> You both think we should release 1.19 only once the interface work is
>>> fully done? Be it in 3 months or in a year?
>>
>> I hope that we will be done by November.
>
>
> Hope dies last. :)
>
> More seriously. I have a hard time seeing that interfaces is fully done
> in November when we still argue promises (as a very basic part) again.
>

 From what I remember, we decided promises will not take a key part in 
this. We will not rely on promises at this point.

> The feedback I got so far is: make it a feature based release and only
> release it when interfaces as a showstopper bug is done.
>
> I have my doubts this will fly, but if nobody else thinks this idea will
> not work I stash my concerns and will see how I call help processing
> this release. Just never ask me when this release will happen or point
> out that distro or product schedules might need it done before XX :)
>
>>
>>> Our track record for doing feature based releases is not really
>>> promising to be honest. :)
>>
>> Ah ah ah. Well, to be honest, I have asked to get at least 2 releases
>> cycle for efl interface work. We tried to stretch it to make that
>> shorter, but that didn't fly. Now we are back to the original
>> schedule, let's see if it is a bit more accurate.
>>
>>> This would need at least a detailed list with tasks which need to be
>>> done before the release could happen. Plus a definition what done means
>>> in the context of the task.
>>
>> I will try to make later this week an email about what needs to still
>> be done for efl interface work.
>
> Looking forward to it. Maybe this gives some information we can base any
> planning on.
>
> regards
> Stefan Schmidt
>
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/enlightenment] master 01/01: mixer: lock up the slider for the case a drag is in progress

[Marcel Hollerbach]

bu5hm4n pushed a commit to branch master.

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

commit eed35d3c4f77f48b6bdb46611e4bba4cabb08c41
Author: Marcel Hollerbach 
Date:   Wed Sep 14 10:20:56 2016 +0200

mixer: lock up the slider for the case a drag is in progress

if you click on the slider in the gadget the slider jumps a back to the
old volume and then to the new volume, this is because a pulseaudio
update is sent while the last changed event was called, but not the
drag_stop callback.
---
 src/modules/mixer/e_mod_main.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/src/modules/mixer/e_mod_main.c b/src/modules/mixer/e_mod_main.c
index db7a1d7..970c1ab 100644
--- a/src/modules/mixer/e_mod_main.c
+++ b/src/modules/mixer/e_mod_main.c
@@ -127,7 +127,8 @@ static void
 _mixer_popup_update(Instance *inst, int mute, int vol)
 {
elm_check_state_set(inst->check, !!mute);
-   elm_slider_value_set(inst->slider, vol);
+   if (!evas_object_data_del(inst->slider, "__lock"))
+ elm_slider_value_set(inst->slider, vol);
 }
 
 static void _popup_del(Instance *inst);
@@ -399,6 +400,14 @@ _slider_drag_stop_cb(void *data EINA_UNUSED, Evas_Object 
*obj,
Emix_Sink *s = (Emix_Sink *)mixer_context->sink_default;
int val = s->volume.volumes[0];
elm_slider_value_set(obj, val);
+   evas_object_data_del(obj, "__lock");
+}
+
+static void
+_slider_drag_start_cb(void *data EINA_UNUSED, Evas_Object *obj,
+ void *event EINA_UNUSED)
+{
+   evas_object_data_set(obj, "__lock", (void*)1);
 }
 
 static void
@@ -466,6 +475,7 @@ _popup_new(Instance *inst)
elm_slider_min_max_set(slider, 0.0, emix_max_volume_get());
evas_object_smart_callback_add(slider, "changed", _slider_changed_cb, NULL);
evas_object_smart_callback_add(slider, "slider,drag,stop", 
_slider_drag_stop_cb, NULL);
+   evas_object_smart_callback_add(slider, "slider,drag,start", 
_slider_drag_start_cb, NULL);
elm_slider_value_set(slider, volume);
elm_box_pack_end(bx, slider);
evas_object_show(slider);

-- 

Re: [E-devel] EFL packaging on Debian

[Stefan Schmidt]

Hello.

On 14/09/16 02:44, Ross Vandegrift wrote:
> On 09/13/2016 07:07 PM, Stefan Schmidt wrote:
>> On 14/09/16 00:13, Ross Vandegrift wrote:
>>> On 09/13/2016 05:58 PM, Stefan Schmidt wrote:
>>> The current Debian maintainer has been missing, but supposedly returning
>>> soon.
>>
>> Soon as in this year?
>
> Yep, that's what I've heard - of course people's plans change, so who
> knows for sure.
>
>>> Soon, I hope we'll be able to get these into the archive.
>>
>> I have seen you mention this before and I wonder how realistic this hope
>> is. Are you a Debian Developer or maintainer? Do you have a sponsor that
>> would sponsor your non packager uploads?
>
> No, I am not a DD or DM.  But I think I could find a sponsor.  I've been
> waiting for Albin - he's expressed interest to me to be involved, and
> I'd like to wait.  But if it doesn't pan out, I don't think it's the end
> of the road.
>
> I think your pessimism is fair, but hope to help improve the situation.

That would be good :)

>
>>> Hypothesis: E17 on EFL 1.8 might be old, but it's reasonably stable and
>>> useful.  So end-users that do not follow EFL development might not
>>> know/care about new features.  Those that do probably build from source.
>>
>> You think these users do also not care about bug fixes and security
>> fixes? You know many people that are using efl 1.8 and e17 and are happy
>> that Debian does not update to newer versions?
>
> Oh I don't think anyone is happy about it - I haven't been.  But that
> doesn't mean it's been impossible to get by.
>
>  > I talk about Debian unstable here and not some years old
>  > release. (I have been using Debian SID myself for over 10 years and
>  > at that point packages have been updated when new versions came out)
>
> If you have time and interest, I'd be happy to get bug/success reports
> on the packages so far.

I moved my desktops to Fedora a while ago because even with SID I 
sometimes had the problem of missing or outdated packages for a desktop 
experience (not EFL, I compile that myself). I keep running it on a 
headless server. Nothing to test from my side.

regards
Stefan Schmidt

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel