Re: [E-devel] [EGIT] [core/efl] master 01/01: edje_edit: delete gradient funcs prototope

[Vyacheslav Reutskiy]

Hello

On Fri, Sep 18, 2015 at 11:58 AM, Stefan Schmidt 
wrote:

> Hello.
>
> On 18/09/15 10:41, Vyacheslav Reutskiy wrote:
> > Really, I don't like to a remove API's, but they have not body.
> >
> > Stub function as implementation - we can do it, but it's smell as
> > an attempt to revive the corpse. I would not have left this API's,
> > but If some one say that they need and should stay, I revert commit
> > and make new, where it marked as deprecated and have a some
> > stub.
>
> Lets wait some time before reverting anything here. I want to hear at
> least an opinion from Cedric on this. Guess raster might also have
> something to add.
>

Of course wait! I'm not going to do revert, without others opinions


> regards
> Stefan Schmidt
>
>
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

Best regards
Vyacheslav Reutskiy
--
___
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: edje_edit: delete gradient funcs prototope

[Stefan Schmidt]

Hello.

On 18/09/15 10:41, Vyacheslav Reutskiy wrote:
> Really, I don't like to a remove API's, but they have not body.
>
> Stub function as implementation - we can do it, but it's smell as
> an attempt to revive the corpse. I would not have left this API's,
> but If some one say that they need and should stay, I revert commit
> and make new, where it marked as deprecated and have a some
> stub.

Lets wait some time before reverting anything here. I want to hear at 
least an opinion from Cedric on this. Guess raster might also have 
something to add.

regards
Stefan Schmidt

--
___
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: edje_edit: delete gradient funcs prototope

[Stefan Schmidt]

Hello.

On 17/09/15 19:34, Davide Andreoli wrote:
> Indeed they can be deleted, this is probably a leftover from when gradients
> were removed from edje (years ago).
>
> Edje_Edit gradients API was working, and was removed when gradients was
> removed from edje.

Which would have been comit b49c2411bdc7225be249124b2de5f48e5d4be161

They also have been removed from evas a month later (both in 2010). Our 
Evas and Edje 1.0 releases have been in 2011. Which means the feature 
itself was never part of our releases but we still had a public API for 
5 years which did not work. Wow, I really hope I got this wrong somehow. :/

In general I would just say no to a removal of released API symbols. In 
this case the fact that the feature was removed 5 years ago and we have 
no actual code implementing it is convincing to me. Especially as the 
alternatives are  not really flying as well a) bring back gradient or b) 
mark them as deprecated which does not solve the problem that we have no 
implementations.

Having stub function as implementation which simply error out could be 
ok if we want to really go the deprecation route. I see not much use in 
it though.

What do others think here?

Cedric, as you removed the gradient feature at that time and now 
introducing ector, which might have a use for gradients, I look for your 
opinion here.

regards
Stefan Schmidt

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

Re: [E-devel] [EGIT] [core/elementary] master 01/01: dnd/x11: correct coordinates in pos callback

[Vyacheslav Reutskiy]

Hello,
As I remember we not use 'printf' for print logging.

Best regards
Vyacheslav Reutskiy


On Fri, Sep 18, 2015 at 11:37 AM, Thiep Ha  wrote:

> jackdanielz pushed a commit to branch master.
>
>
> http://git.enlightenment.org/core/elementary.git/commit/?id=0363553dfced5eb0a8000c3493bf2fb53407f589
>
> commit 0363553dfced5eb0a8000c3493bf2fb53407f589
> Author: Thiep Ha 
> Date:   Fri Sep 18 11:30:23 2015 +0300
>
> dnd/x11: correct coordinates in pos callback
>
> Summary:
> The x, y coordinates in pos callback should be relative to
> the top-left of the object.
> This patch corrects the x,y coordinates and adds poscb to elementary
> test
> to clearly show the bug case.
>
> Test:
>   Run Genlist Dnd Dflt Anim with the change in this patch.
>   Drag an item to other genlist and see the printed out item, x, y.
>
> @fix
>
> Reviewers: JackDanielZ
>
> Subscribers: seoz
>
> Differential Revision: https://phab.enlightenment.org/D3063
> ---
>  src/bin/test_dnd.c | 30 ++
>  src/lib/elm_cnp.c  | 11 +--
>  2 files changed, 35 insertions(+), 6 deletions(-)
>
> diff --git a/src/bin/test_dnd.c b/src/bin/test_dnd.c
> index 4b6124a..dd24585 100644
> --- a/src/bin/test_dnd.c
> +++ b/src/bin/test_dnd.c
> @@ -217,6 +217,14 @@ _strndup(const char *str, size_t len)
> return ret;
>  }
>
> +static void
> +_gl_poscb(void *data EINA_UNUSED, Evas_Object *obj, Elm_Object_Item *it,
> Evas_Coord x, Evas_Coord y, int xposret, int yposret, Elm_Xdnd_Action
> action EINA_UNUSED)
> +{
> +   printf("<%s> <%d> obj: %p, item: %p <%s>, x y: %d %d, posret: %d %d\n",
> +  __func__, __LINE__, obj, it, elm_object_item_text_get(it),
> +  x, y, xposret, yposret);

+}
> +
>  static Eina_Bool
>  _gl_dropcb(void *data EINA_UNUSED, Evas_Object *obj, Elm_Object_Item *it,
> Elm_Selection_Data *ev, int xposret EINA_UNUSED, int yposret)
>  {  /* This function is called when data is dropped on the genlist */
> @@ -761,18 +769,32 @@ void
>  test_dnd_genlist_default_anim(void *data EINA_UNUSED, Evas_Object *obj
> EINA_UNUSED, void *event_info EINA_UNUSED)
>  {
> char buf[PATH_MAX];
> -   Evas_Object *win, *gl, *bxx;
> +   Evas_Object *win, *gl, *bxx, *bx2, *lb;
> int i, j;
>
> win = elm_win_util_standard_add("dnd-genlist-default-anim",
> "DnD-Genlist-Default-Anim");
> elm_win_autodel_set(win, EINA_TRUE);
>
> bxx = elm_box_add(win);
> -   elm_box_horizontal_set(bxx, EINA_TRUE);
> +   elm_box_horizontal_set(bxx, EINA_FALSE);
> evas_object_size_hint_weight_set(bxx, EVAS_HINT_EXPAND,
> EVAS_HINT_EXPAND);
> elm_win_resize_object_add(win, bxx);
> evas_object_show(bxx);
>
> +   lb = elm_label_add(win);
> +   elm_object_text_set(lb, "Drag and drop between genlists with default
> anim.");
> +   evas_object_size_hint_min_set(lb, 0, 50);
> +   evas_object_size_hint_align_set(lb, EVAS_HINT_FILL, 0.5);
> +   evas_object_show(lb);
> +   elm_box_pack_end(bxx, lb);
> +
> +   bx2 = elm_box_add(win);
> +   elm_box_horizontal_set(bx2, EINA_TRUE);
> +   evas_object_size_hint_align_set(bx2, EVAS_HINT_FILL, EVAS_HINT_FILL);
> +   evas_object_size_hint_weight_set(bx2, EVAS_HINT_EXPAND,
> EVAS_HINT_EXPAND);
> +   evas_object_show(bx2);
> +   elm_box_pack_end(bxx, bx2);
> +
> itc1 = elm_genlist_item_class_new();
> itc1->item_style = "default";
> itc1->func.text_get = gl_text_get;
> @@ -791,7 +813,7 @@ test_dnd_genlist_default_anim(void *data EINA_UNUSED,
> Evas_Object *obj EINA_UNUS
>_gl_item_getcb,
>NULL, NULL,
>NULL, NULL,
> -  NULL, NULL,
> +  _gl_poscb, NULL,
>_gl_dropcb, NULL);
>
>  elm_drag_item_container_add(gl, ANIM_TIME, DRAG_TIMEOUT,
> @@ -802,7 +824,7 @@ test_dnd_genlist_default_anim(void *data EINA_UNUSED,
> Evas_Object *obj EINA_UNUS
>  //elm_genlist_mode_set(gl, ELM_LIST_LIMIT);
>  evas_object_size_hint_weight_set(gl, EVAS_HINT_EXPAND,
> EVAS_HINT_EXPAND);
>  evas_object_size_hint_align_set(gl, EVAS_HINT_FILL,
> EVAS_HINT_FILL);
> -elm_box_pack_end(bxx, gl);
> +elm_box_pack_end(bx2, gl);
>  evas_object_show(gl);
>
>  for (i = 0; i < 20; i++)
> diff --git a/src/lib/elm_cnp.c b/src/lib/elm_cnp.c
> index d9e6c51..00d5aa5 100644
> --- a/src/lib/elm_cnp.c
> +++ b/src/lib/elm_cnp.c
> @@ -1331,10 +1331,13 @@ _x11_dnd_dropable_handle(Dropable *dropable,
> Evas_Coord x, Evas_Coord y, Elm_Xdn
>   {
>  if (last_dropable == dropable) // same
>{
> + Evas_Coord ox, oy;
> +
>   cnp_debug("same obj dropable %p\n", dropable->obj);
> + evas_object_geometry_get(dropable->obj, , , NULL,
> NULL);
>   EINA_INLIST_FOREACH_SAFE(dropable->cbs_list, itr, cbs)
>  if ((cbs->types & dropable->last.format) && cbs->poscb)
> -  

Re: [E-devel] [EGIT] [core/efl] master 01/01: edje_edit: delete gradient funcs prototope

[Jean-Philippe André]

Hi,

On Fri, Sep 18, 2015 at 7:00 PM, Vyacheslav Reutskiy  wrote:

> Hello
>
> On Fri, Sep 18, 2015 at 11:58 AM, Stefan Schmidt 
> wrote:
>
> > Hello.
> >
> > On 18/09/15 10:41, Vyacheslav Reutskiy wrote:
> > > Really, I don't like to a remove API's, but they have not body.
> > >
> > > Stub function as implementation - we can do it, but it's smell as
> > > an attempt to revive the corpse. I would not have left this API's,
> > > but If some one say that they need and should stay, I revert commit
> > > and make new, where it marked as deprecated and have a some
> > > stub.
> >
> > Lets wait some time before reverting anything here. I want to hear at
> > least an opinion from Cedric on this. Guess raster might also have
> > something to add.
> >
>
> Of course wait! I'm not going to do revert, without others opinions
>
>
If there is a symbol in the existing .so files, then the API must not be
removed. An empty stub function is necessary for legacy compatibility. If
an application was (purposedly or erroneously) linking to this function,
then it will fail to link to EFL at runtime. This would not be acceptable.

So, mark the functions as deprecated, but keep a stub if there were public
symbols before. If there was no symbol, then application build-time linking
would fail, so it should be fine to remove the stub.

Best regards,

-- 
Jean-Philippe André
--
___
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: edje_edit: delete gradient funcs prototope

[David Seikel]

On Fri, 18 Sep 2015 13:00:50 +0300 Vyacheslav Reutskiy
 wrote:

> Hello
> 
> On Fri, Sep 18, 2015 at 11:58 AM, Stefan Schmidt
>  wrote:
> 
> > Hello.
> >
> > On 18/09/15 10:41, Vyacheslav Reutskiy wrote:
> > > Really, I don't like to a remove API's, but they have not body.
> > >
> > > Stub function as implementation - we can do it, but it's smell as
> > > an attempt to revive the corpse. I would not have left this API's,
> > > but If some one say that they need and should stay, I revert
> > > commit and make new, where it marked as deprecated and have a some
> > > stub.
> >
> > Lets wait some time before reverting anything here. I want to hear
> > at least an opinion from Cedric on this. Guess raster might also
> > have something to add.
> >
> 
> Of course wait! I'm not going to do revert, without others opinions

How is this suitable for keeping around at all if it never had any
functionality behind it?  Accidental NOPs don't really need to be
deprecated, they don't do anything, so no one is relying on them to do
anything.

Any new thing based on ector might very well have nothing in common
with the ancient gradient stuff.  Don't think it would be a good idea
to try to squeeze new stuff into ancient API that got removed.

Not to mention that in EFL, it's traditional to throw out old stuff, and
replace it with completely new stuff.

It's only left over crap that never did anything, my vote is to just
remove it.  The result of just removing it - a very few compile time
errors that are easily fixed, remove the function calls that didn't do
anything anyway.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
___
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: edje_edit: delete gradient funcs prototope

[Vyacheslav Reutskiy]

Really, I don't like to a remove API's, but they have not body.

Stub function as implementation - we can do it, but it's smell as
an attempt to revive the corpse. I would not have left this API's,
but If some one say that they need and should stay, I revert commit
and make new, where it marked as deprecated and have a some
stub.


On Fri, Sep 18, 2015 at 11:13 AM, Stefan Schmidt 
wrote:

> Hello.
>
> On 17/09/15 19:34, Davide Andreoli wrote:
> > Indeed they can be deleted, this is probably a leftover from when
> gradients
> > were removed from edje (years ago).
> >
> > Edje_Edit gradients API was working, and was removed when gradients was
> > removed from edje.
>
> Which would have been comit b49c2411bdc7225be249124b2de5f48e5d4be161
>
> They also have been removed from evas a month later (both in 2010). Our
> Evas and Edje 1.0 releases have been in 2011. Which means the feature
> itself was never part of our releases but we still had a public API for
> 5 years which did not work. Wow, I really hope I got this wrong somehow. :/
>
> In general I would just say no to a removal of released API symbols. In
> this case the fact that the feature was removed 5 years ago and we have
> no actual code implementing it is convincing to me. Especially as the
> alternatives are  not really flying as well a) bring back gradient or b)
> mark them as deprecated which does not solve the problem that we have no
> implementations.
>
> Having stub function as implementation which simply error out could be
> ok if we want to really go the deprecation route. I see not much use in
> it though.
>
> What do others think here?
>
> Cedric, as you removed the gradient feature at that time and now
> introducing ector, which might have a use for gradients, I look for your
> opinion here.
>
> 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] [EGIT] [core/elementary] master 01/01: slider: slider should be focused, when slider is handled with mouse or touch event.

[Daniel Juyung Seo]

ping?

On Wed, Sep 16, 2015 at 5:34 PM, Daniel Juyung Seo  wrote:
> Yo,
>
> This is not always true.
> We need to consider ELM_FOCUS_MOVE_POLICY_KEY_ONLY. In that case, the
> slide should not be focused by dragging.
>
> Thanks,
> Daniel
>
> On Wed, Sep 16, 2015 at 10:16 AM, Hosang Kim  wrote:
>> hermet pushed a commit to branch master.
>>
>> http://git.enlightenment.org/core/elementary.git/commit/?id=1262c24a72a314bc3dd1de014283068cd390e88c
>>
>> commit 1262c24a72a314bc3dd1de014283068cd390e88c
>> Author: Hosang Kim 
>> Date:   Wed Sep 16 10:10:32 2015 +0900
>>
>> slider: slider should be focused, when slider is handled with mouse or 
>> touch event.
>>
>> Summary: slider is not focused after slider is dragged.
>>
>> Test Plan: elementary_test -> slider
>>
>> Reviewers: woohyun, seoz, smohanty, cedric, raster
>>
>> Differential Revision: https://phab.enlightenment.org/D3057
>> ---
>>  src/lib/elm_slider.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/src/lib/elm_slider.c b/src/lib/elm_slider.c
>> index bffab0a..25cd4a7 100644
>> --- a/src/lib/elm_slider.c
>> +++ b/src/lib/elm_slider.c
>> @@ -240,6 +240,8 @@ _drag_start(void *data,
>>  const char *emission EINA_UNUSED,
>>  const char *source EINA_UNUSED)
>>  {
>> +   if (!elm_widget_focus_get(data))
>> + elm_object_focus_set(data, EINA_TRUE);
>> _slider_update(data, EINA_TRUE);
>> eo_do(data, eo_event_callback_call(ELM_SLIDER_EVENT_SLIDER_DRAG_START, 
>> NULL));
>> elm_widget_scroll_freeze_push(data);
>> @@ -644,6 +646,8 @@ _spacer_down_cb(void *data,
>> edje_object_part_drag_value_set
>>   (wd->resize_obj, "elm.dragable.slider",
>>   button_x, button_y);
>> +   if (!elm_widget_focus_get(data))
>> + elm_object_focus_set(data, EINA_TRUE);
>> _slider_update(data, EINA_TRUE);
>> eo_do(data, eo_event_callback_call(ELM_SLIDER_EVENT_SLIDER_DRAG_START, 
>> NULL));
>> elm_layout_signal_emit(data, "elm,state,indicator,show", "elm");
>>
>> --
>>
>>
>
>
>
> --
> Daniel Juyung Seo (SeoZ)



-- 
Daniel Juyung Seo (SeoZ)

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