date:20160613

Re: [E-devel] promises...

2016-06-13 Thread The Rasterman

On Wed, 8 Jun 2016 10:07:33 -0700 Cedric BAIL  said:

> On Wed, Jun 8, 2016 at 8:10 AM,   wrote:
> > On Wed, Jun 08, 2016 at 08:16:20PM +0900, Carsten Haitzler wrote:
> >>
> >  [...]
> >> they should be eo objects.
> >
> > I wondered in the beginning why promises are not a eo object, comparing the
> > two models shows that it can be dangerous moving promises to a Eo.Base
> > class.
> >
> > Take a look at the events, when in a promise the then callback is
> > called the callback is unsubscribed, and never called again. When a then
> > callback is attached after the value is set the then callback is called
> > while beeing added. So this is a completly different sematic compared to
> > Eo.Base. Of course a implementation can be treated to do smth. like
> > that, but i think its confusing to users of a api, if objects behave
> > differently under the same base api.
> >
> > Also when attaching a then_cb you will get a ref of the promise, so as
> > long as your then_cb is not called the promise will not be freed. This
> > is also something which does not play with the ref/unref system of
> > Eo.Base.
> >
> > Basically you can say, after the then_cb you just have to nuke your
> > reference to your promise, at the best dont keep a reference to it.
> >
> > So all in all the concept of A Promise inheriting from Eo.Base doesnt
> > sound sane to me, and looks like a huge confusion you can get in. So I
> > would prefer to keep the promises as they are, exept the idea of using
> > Eo_Id to make the pointer more secure.
> 
> Good point. It should have been a generic infrastructure anyway. Will
> work on that.

Don't do this.. because it shouldn't! promises should be eo objects! don't go
duplicating this in eina just because you can't see that eina promises are
objects.


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

2016-06-13 Thread The Rasterman

On Wed, 8 Jun 2016 22:37:55 +1000 David Seikel  said:

> I'm just gonna pipe in here a little bit.
> 
> On Wed, 8 Jun 2016 20:16:20 +0900 Carsten Haitzler (The Rasterman)
>  wrote:
> 
> > > If history tell us, our existing solution is not usable, but prove
> > > me wrong and show me how amazing our current limited set of
> > > asynchronous API is used by so many people. Now just think that we
> > > are expanding  
> > 
> > as above. ecore_con. ecore_con_url, preload, timer, job,
> > animator,  all used.
> 
> I use ecore_con, timer, job, and animator in a couple of my projects.
> The first two I use a lot in my huge project.  ecore_con_url and
> preload I just haven't bothered to try out yet.  I also use EFL
> threads and ecore fd handler for some async stuff.
> 
> There was one thing I was thinking that I might try promises on, once
> the API and arguments are settled, replacing timer and job for
> sequencing some async startup stuff.  That would still leave ecore_con,
> timer, and threads heavily used in that project, but I think that's the
> only place I use job.  Promises as initially described to me seems like
> a slightly better fit than timers and jobs for this startup stuff.
> 
> I've not actually looked at promises yet though, but I agree in
> principle with Raster when he says that things should be consistent and
> use the same infrastructure.  Having said that, now I'm wondering why we
> can't just extend jobs?

actually jobs in current efl are promises, so it's kind of inverted. but
promises are objects. a job is now a promise. you want to track it and
cancel/unref/whatever it hwne you no longer need it. this is why i keep saying
they are objects thus should be eo.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

2016-06-13 Thread The Rasterman

On Wed, 8 Jun 2016 17:10:07 +0200 marcel-hollerb...@t-online.de said:

> Hello,
> 
> On Wed, Jun 08, 2016 at 08:16:20PM +0900, Carsten Haitzler wrote:
> >
>  [...]
> > they should be eo objects.
> 
> I wondered in the beginning why promises are not a eo object, comparing the 
> two models shows that it can be dangerous moving promises to a Eo.Base class.

how so?

> Take a look at the events, when in a promise the then callback is
> called the callback is unsubscribed, and never called again. When a then
> callback is attached after the value is set the then callback is called
> while beeing added. So this is a completly different sematic compared to
> Eo.Base. Of course a implementation can be treated to do smth. like
> that, but i think its confusing to users of a api, if objects behave
> differently under the same base api.

i disagree. having eina_promise_ref in addition to eo_ref, having yet another
copy of the oi id indirection to make promise i'ds safe etc. is worse than
making a promise live within eo api. as i keep saying - the solution is worse
than the disease.

we dont HAVE to use eo event callbacks though. we could special case then/else
in eo promises and of course require those to be hand bound specifically. eo
objects that delete after their task is done can be tagged in eo as such
specific objects, just like proxy objects delete themselves after use. it isnt
confusing when its tagged. it's just a PAIN to have eina_promise vs eo_* in c.
in c++, js, lua promises are normal objects with all normal object operations
of referencing, gc'ing, deletion etc. just like eo is for c. in other langs they
use the SAME object api as all other objects, why are they so special in c
where they should not? all they do is cause pain in c. in other langs they are
full blown normal objects as i am saying they should be in c.

we can do:

eo_promise_then(promise, done_cb, err_cb, data);

it's a special manually bound method that has the 2 cb's. all the eina_promise
progress stuff can be dropped and done as eo event extensions. any events until
the done/err can be extended as much as desired via eo callbaks. it nukes a
huge amount of the eina promise api. no need for the progress_cb stuff and only
extend where needed and use normal inheritance/classes for this. have a promise
progress class for anything needing to extend promises to do progress that
inherits from the promise class. and so on...

> Also when attaching a then_cb you will get a ref of the promise, so as
> long as your then_cb is not called the promise will not be freed. This
> is also something which does not play with the ref/unref system of
> Eo.Base.

see above. and we already define proxy objects to specially delete themselves
after their furst use. is this no different to the promise deleting itself
after the then/error cb? it's aproprty of the object. it's specific to
promises. you have to learn this behaviour with eina_promise objects anyway and
in c++, js and lua you have normal "regular objects" that are hiding the
eina_promises that behave exactly this way... so the argument that promises are
somehow special and cant be eo objects falls apart the moment you are in c++,
js or lua where they ARE such objects. so i call the argument "bogus" on the
best of days.

> Basically you can say, after the then_cb you just have to nuke your
> reference to your promise, at the best dont keep a reference to it.

we don't need to tell people to nuke their reference. the obj class just does
an eo_del on itself after calling the then/error cb. you don't need to. if
someone as an extra eo_ref on the obj then it stays alive until that ref is
released - this is exactly how eina promises work now. there is nothing weird
or wrong with eo objects working this way too. they already do - proxy objects
for parts.

> So all in all the concept of A Promise inheriting from Eo.Base doesnt
> sound sane to me, and looks like a huge confusion you can get in. So I
> would prefer to keep the promises as they are, exept the idea of using
> Eo_Id to make the pointer more secure.

i disagree. think of operator overloading in c++. a + may not mean a
mathematical +. i can ave a string lass that makes + append the strings. this
is common. it makes a common tool work appropriately for the task. people seem
to be able to deal with this.

same with eo promise objects. they are objects with a specific behaviour. they
delete after their then/error cb is called. they only allow a single then/error
cb. you CAN add event cb's to listen for their deletion with del events, or you
can extend them with progress cb's etc.

there is no reason the then/else cb's have to be a different cb prototype to eo
event callbacks. the return value can go unused as there are no more cb's to
skip after this so its just a dummy return value. it saves a lot of mental
effort to remember the different callback types. the return doesn't hurt as it
has no effect. the value stuff can be passed in the event info

Re: [E-devel] promises...

2016-06-13 Thread The Rasterman

On Sun, 12 Jun 2016 11:02:37 -0700 Cedric BAIL  said:

> On Wed, Jun 8, 2016 at 4:16 AM, Carsten Haitzler  wrote:
> > On Mon, 6 Jun 2016 06:01:13 +0200 Cedric BAIL  said:
> 
> 
> 
> >> >> You just can't do with eo event what promise do. Eo event are a
> >> >
> >> > it's not NECESSARY to do anything new. timeout can be an eo obj that
> >> > deletes itself after the one-shot callback. it doesn't need a promise.
> >> > same as job. i can't add promises as children to an obj and make sure
> >> > they get autodeleted when parent is. i have to do this all by hand now.
> >>
> >> It is a terrible mistake to override eo object lifecycle. This is an
> >> absolute no go as a solution. Anything that bypass the refcounting and
> >> ownership of an eo object lead to massive issue and trouble. We can
> >> not implement auto deletion of eo object outside of the reference
> >> count system.
> >
> > this doesn't bypass it. it USES it. the object unrefs/del's itself. when
> > done. when an evas canvas is deleted it deletes all child objects. no code
> > is explicitly in the app deleting the objects. it's done internally.
> 
> That's exactly what I mean by bypass. Evas canvas delete object
> because the parent die. Now, in the case of a promise eo object, there
> is no parent that will disapear to do the unref/del, it is when all
> the listener have received the value, that the promise disapear. If
> you want to use normal eo lifecycle for that, it means that the object
> has to delete itself. And this is bad. This is exactly what
> ecore_timer where historically doing. They were not linked to any
> parent and would just vanish under your feet. This is what tricked you
> into thinking the bug was in the timeout promise while it was in the
> handling of the lifecycle of the timer itself.

and for promises its the "parent action" the download, the async property
fetch, the file load etc. that is the parent conceptually and it deletes the
promise representing it in the wild.

> Reading what you say, you are advocating for using the normal eo
> lifecycle and not letting itself commit succide, which is the proper
> way to handle eo object. Now how can that work with promise ? No idea.

YES I AM. as jp already said. we have proxy objects that self-delete on first
use in another function. promises self-delete when the action is done - same
idea. of course it can work. it works just fine. we do it already. there is no
"proper way" to handle eo deletion other than objects ARE deleted. the
convention is parents del children. del otherwise can happen anywhere by
anything. there is no magical rule otherwise.

> Promise are a promise to deliver something in the future. In themself
> they have no propery and no function. They aren't object, they are

of course they are an object. they old a success/error callback. they HOLD the
value content until suhc a cb can be set to get the value. they can be ref'd
and unref'd and kept around for along as desired. in js, c++ and lua they are
actual objects because these languages ONLY have an object, or a basic
variable. so they are objects there. you keep the object around so you can
cancel it. they are objects. they are as much objects as eo objects are.

> delivering object. Their lifecycle is that they either deliver or
> fail, they never "die" before that. It is a guaranty that they deliver
> a callback whatever happen to everyone that registered to listen them.
> This doesn't match at all eo object lifecycle.

proxy objects. need i say more. they die after first use in another func. and
either way this is a lifecycle SPECIFIED by the promise object. it is HOW they
are meant to work. they are MEANT to delete themselves when done (after calling
success/err callbacks). self deletion isn't something eo forbids at all.

> > you are totally inconsistent thinking promises are some kind of magically
> > special thing that is not an object... yet in all ways it works *IS* an
> > object.
> 
> If you stretch the definition of an object outside of what Eo is, yes,
> but by that standard everything could be an object. If you limit your
> definition to what Eo is and I mean by that Eo lifecycle and events,
> it doesn't. Oh, and there is plenty of stuff in an Eo object that are
> useless for promise.

eo doesn't define an object cannot self delete. so it matches. eo events are
not useless for callbacks - its how you can extend progress etc. it makes far
more sense than what eina_promise has now. it allows inheritance and extension.
eina_promise is totally fixed in stone. and so what if key/value data is not
useful. it doesnt cost anything except a ptr to have as a feature and all eo
objects have it and its not useful on every single object BUT... it's useful
ENOUGH to be in the base class. so what then? a promise uses a bit more ram.
this isnt about ram or efficiency but of usability and eina _promises are FAr
LESS USABLE than if they were eo

Re: [E-devel] Preparation for release: Removal of EFL_EO_API_SUPPORT and etc

2016-06-13 Thread Jean-Philippe André

Hi,

On 14 June 2016 at 03:48, Cedric BAIL  wrote:

> Hello,
>
> On Mon, Jun 13, 2016 at 7:01 AM, Stefan Schmidt 
> wrote:
> > On 13/06/16 14:18, Stefan Schmidt wrote:
> >> On 13/06/16 13:16, Tom Hacohen wrote:
> >>> As part of the development process of the new Eo API we marked all of
> >>> the API all around as beta. We mainly use EFL_EO_API_SUPPORT, but I
> >>> think we maybe also use EFL_BETA_API_SUPPORT, need to verify that.
> >>>
> >>> Anyhow, now is time to remove these tags (where appropriate), so these
> >>> APIs are released.
> >>>
> >>> I guess we can just remove all of the occurrences of the EO one, but we
> >>> need to be more careful with the other one.
> >>>
> >>> Is there anyone who has time to take care of this? Stefan? Or should I
> >>> try to tackle it on Thursday when I'm done with travel and other stuff
> I
> >>> need to deal with?
> >>>
> >> I will have a look at it.
> >>
> >> Are we really sure that all APIs behind  the EFL_EO_API_SUPPORT are
> >> really finsalised?
> >>
> >> We might need to come up with a list of them and brign them up here for
> >> the audience.
> >>
> >
> > After removal of the EFL_EO_API_SUPPORT ifdef we have the following new
> > APIs that we need to support. (git grep "ifdef EFL_EO_API_SUPPORT")
> > I did only list areas here as listing every single new function, struct,
> > event, etc would just be to big.
> >
> > Ecore:
> > o ecore_poller
> > o ecore_loop_timer
>
> I can't find that one. Do you have a pointer ?
>
> > o ecore_exe
>
> All the ecore one should stay under BETA for now.
>
> > o efl_loop
> > o efl_loop_args
> > o efl_loop_user
> > o efl_loop_fd
> >
> > Ecore_Con:
> > o efl_network
> > o efl_network_server
> > o efl_network_connector
> > o efl_network_client
> > o efl_network_url
>
> All Ecore_Con/Efl_Network need to stay under BETA we haven't had the
> time to take care of them.
>
> > Edje:
> > o edje_object
>
> Will need to be renamed and cleaned as Efl.Canvas.Layout.
>
> > o edje_edit
>
> Shouldn't be an Eo object.
>
> > Eio:
> > o eio_job
> > o eio_sentry
> > o eio_model
>
> Some rename are still going to happen with those, but otherwise that
> is fine for now.
>
> > Emotion:
> > o emotion_object
>
> This should have been renamed with Efl.Canvas.Video. I did think the
> patch did land for that, will have to look at it.
>
> > Evas:
> > o canvas/efl_ui_draggable
> > o canvas/efl_ui_clickable
> > o canvas/efl_ui_scrollable
> > o canvas/efl_ui_selectable
> > o canvas/efl_ui_zoomable
> > o canvas/evas_canvas
>

Evas.Canvas will not be installed. The only canvas API (evas, ecore_evas,
elm_win) should be Efl.Ui.Window.



> > o canvas/efl_canvas_rectangle
> > o canvas/evas_textblock
>

Efl.Canvas.Text? tasn and herdsman are on it.



> > o canvas/efl_canvas_polygon
> > o canvas/evas_object_smart
> > o canvas/evas_smart_clipped
>

These two (esp. smart object) are a problem. Hard to get rid of (we need
the inheritance),
I would go for this solution:
1. rename to Efl.Canvas.Group.Internal (or smart, or whatever)
2. rename all functions to group_ something, or smart_ something to avoid
method clashes
3. mark all functions @protected

Most functions are actually clashing with basic evas object functions
(clip, hide, no_render, ...). Not sure if we can simply just make evas
object smart implement the basic methods.
We should also probably mark everything as @beta (meaning unstable, do not
use).



> > o canvas/evas_common_interface
>

This is a bit a of a problem. It returns the Evas which we don't really
want to expose. But use it extensively inside EFL, and it's hard to
implement as legacy-only.
Make its single property just @protected and @beta?



> > o canvas/evas_object
>

Rename to Efl.Canvas.Object - not a big deal
But many methods might need some cleanup.



> > o canvas/evas_canvas3d_object
> > o canvas/evas_canvas3d_texture
> > o canvas/evas_canvas3d_material
> > o canvas/evas_canvas3d_light
> > o canvas/evas_canvas3d_primitive
> > o canvas/evas_canvas3d_mesh
> > o canvas/evas_canvas3d_node
> > o canvas/evas_canvas3d_camera
> > o canvas/evas_canvas3d_scene
>
> All the canvas 3d stay a BETA API.
>
> > o canvas/efl_canvas_image_internal
> > o canvas/efl_canvas_image
> > o canvas/efl_canvas_snapshot
> > o canvas/efl_canvas_proxy
> > o canvas/efl_canvas_scene3d
> > o canvas/evas_vg
> > o canvas/efl_vg
> > o canvas/efl_vg_container
> > o canvas/efl_vg_shape
> > o canvas/efl_vg_gradient
> > o canvas/efl_vg_gradient_linear
> > o canvas/efl_vg_gradient_radial
>
> All the VG API should also stay as a BETA API for now.
>
> > o canvas/efl_event_input
> > o canvas/efl_event_pointer
> > o canvas/efl_event_key
> >
> > Elementary:
> > o efl_ui_box
> > o efl_ui_box_flow
> > o efl_ui_grid
> > o efl_ui_grid static
> > o efl_ui_image
> > o efl_ui_win
> > o efl_ui_win_standard
> > o efl_ui_nstate
> > o elc_combobox
> > o elc_ctxpopup
> > o elc_fileselector
> > o elc_fileselector_button
> > o elc_fileselector_entry
> > o

Re: [E-devel] promises...

2016-06-13 Thread Jean-Philippe André

Hi Felipe & Cedric,


Thanks for explaining the lifecycle in detail, ... but I'm still not
convinced :)


On 14 June 2016 at 02:28, Felipe Magno de Almeida <
felipe.m.alme...@gmail.com> wrote:

> Sorry for top-posting. But let me summarize the Promise lifetime:
>
> A Promise when created starts with a ref-count of 1.
> If the promise is not needed anymore, it should be
> unref'ed (if no eina_promise_then is made, either
> directly or by eina_promise_all/eina_promise_race).
>
> The first eina_promise_then _steals_ the first
> reference, the others eina_promise_then
> increments the reference count.
>
> When the promise is fulfilled (by value_set or error_set),
> then each call to a eina_promise_then decrements
> the reference count by 1.
>
> When the reference count reaches 0 _and_ the
> promise is fulfilled the promise is deleted (both
> conditions must be true, if just one is true it
> continues to exist).
>
> So, valid cases:
>
> Eina_Promise* p = ..;
> eina_promise_then(p, ...);
> // promise will be deleted
> // when callback for the then is called
>
> Eina_Promise* p = ...;
> eina_promise_unref(p);
> // Promise will be freed when promise is fulfilled
> // by error_set or value_set
>
> Eina_Promise* p = ...;
> eina_promise_then(p, ...);
> eina_promise_then(p, ...);
> // promise will be deleted
> // when callback for the then is called
>
> Eina_Promise* p = ...;
> eina_promise_all(p, ...);
> eina_promise_then(p, ...);
> // promise will be deleted
> // when callback for the then is called
>
> Eina_Promise* p = ...;
> eina_promise_all(p, ...);
> // promise will be deleted
> // when callback for the then is called
>
>
So my understanding here is that this can work because a promise can not
ever be synchronous.
In other words, eina_promise_then can never trigger the success/error
callback to be called synchronously, otherwise the above reference count
system falls apart.

While this approach is convenient, it means that we can use an object
(promise) we don't hold any reference on (after first _then).
This is weird :)



> Etc..
>
> Regards,
> --
> Felipe Magno de Almeida
>
>
> On Mon, Jun 13, 2016 at 2:17 PM, Cedric BAIL  wrote:
> > Hello,
> >
> > On Sun, Jun 12, 2016 at 10:13 PM, Jean-Philippe André 
> wrote:
> >> On 13 June 2016 at 03:02, Cedric BAIL  wrote:
> >>> On Wed, Jun 8, 2016 at 4:16 AM, Carsten Haitzler  >
> >>> wrote:
> >>> > On Mon, 6 Jun 2016 06:01:13 +0200 Cedric BAIL 
> >>> said:
> >>> > and you can do the same with eo - you can store the result until cb's
> >>> added or
> >>> > until a go/done/whatever api is called. but that on;y matters if you
> >>> want a
> >>> > specific cb for that specific action. in general if you want that hen
> >>> you want
> >>> > a real object to be returned so you can manage it like other objects.
> >>>
> >>> As said before, basically what you want is an Eo object which doesn't
> >>> behave like a normal eo object. Having its own meaning for ref/unref,
> >>> for events and life cycle. At this point, I don't see how it will be
> >>> easier for people and not more confusing ?
> >>
> >> Efl.Part are EO objects that die after a single function call.
> >> So, we already have objects with a different lifecycle.
> >
> > Yes, but you are not supposed to interact with that said object more
> > than with just one function. What happen if someone do an
> > eo_ref/eo_unref on it ?
>

You can eo_ref() before calling a function, this gives you a "strong" ref
that you then need to eo_unref() manually as well.
This means you can do:

func(efl_part(obj, "a"))

and:

part = eo_ref(efl_part(obj, "a"))
func1(part)
func2(part)
func3(part)
eo_unref(part)

Only func1() will unref the part object implicitely. An internal flag
insures that func2 and func3 don't also trigger an unref.

The same model could be used for promises that we want to stuff into more
than one _then, _race or _all.


>> Events are the same: they call a callback function with a user data and
> an
> >> event info (promise value).
> >
> > No. Event in promise will keep their value until all the reference to
> > the promise exist and each time that a callback is triggered that
> > reference count goes down by one. There is also an absolute guaranty
> > that you can not destroy a promise without having all the reference
> > receiving either a succeed or a fail. Also the returned value of an
> > event handler for then or cancel should be ignored as you can not stop
> > notifying anyone in the chain and the state should stay either success
> > or failure once it has been decided.
>

It is actually a good question whether the return bool is a good idea or
not.
If you return false in evas callbacks, you're gonna be in trouble.

The ON_HOLD flag, now called efl_event_processed_get/set() is a better
approach to stop processing events.



> >> For how long is a promise handle valid?
> >> Is it valid up until

[EGIT] [apps/ephoto] master 01/01: Ephoto: Add Sobel Edge Detection Filter.

2016-06-13 Thread Stephen Houston

okra pushed a commit to branch master.

http://git.enlightenment.org/apps/ephoto.git/commit/?id=6ce5ec32778ac06c33f3d946ee5dd7a912a11a1a

commit 6ce5ec32778ac06c33f3d946ee5dd7a912a11a1a
Author: Stephen Houston 
Date:   Mon Jun 13 21:20:14 2016 -0500

Ephoto: Add Sobel Edge Detection Filter.
---
 src/bin/ephoto.h|  1 +
 src/bin/ephoto_filters.c| 84 +++--
 src/bin/ephoto_single_browser.c | 17 +
 3 files changed, 99 insertions(+), 3 deletions(-)

diff --git a/src/bin/ephoto.h b/src/bin/ephoto.h
index c5a7dc8..0ef3efe 100644
--- a/src/bin/ephoto.h
+++ b/src/bin/ephoto.h
@@ -149,6 +149,7 @@ void ephoto_filter_cartoon(Evas_Object *main, Evas_Object 
*image);
 void ephoto_filter_posterize(Evas_Object *main, Evas_Object *image);
 void ephoto_filter_sketch(Evas_Object *main, Evas_Object *image);
 void ephoto_filter_invert(Evas_Object *main, Evas_Object *image);
+void ephoto_filter_edge(Evas_Object *main, Evas_Object *image);
 void ephoto_filter_histogram_eq(Evas_Object *main, Evas_Object *image);
 
 /*file functions*/
diff --git a/src/bin/ephoto_filters.c b/src/bin/ephoto_filters.c
index 4758a59..3f73c1d 100644
--- a/src/bin/ephoto_filters.c
+++ b/src/bin/ephoto_filters.c
@@ -13,7 +13,8 @@ enum _Ephoto_Image_Filter
EPHOTO_IMAGE_FILTER_POSTERIZE,
EPHOTO_IMAGE_FILTER_SEPIA,
EPHOTO_IMAGE_FILTER_SHARPEN,
-   EPHOTO_IMAGE_FILTER_SKETCH
+   EPHOTO_IMAGE_FILTER_SKETCH,
+   EPHOTO_IMAGE_FILTER_SOBEL
 };
 
 struct _Ephoto_Filter
@@ -45,6 +46,7 @@ static Eina_Bool _sepia(void *data);
 static Eina_Bool _negative(void *data);
 static Eina_Bool _posterize(void *data);
 static Eina_Bool _dodge(void *data);
+static Eina_Bool _sobel(void *data);
 static Eina_Bool _histogram_eq(void *data);
 
 static Ephoto_Filter *
@@ -511,7 +513,6 @@ _posterize(void *data)
  return EINA_TRUE;
   }
  }
-
_idler_finishing_cb(ef, EINA_FALSE);
 
return EINA_FALSE;
@@ -610,6 +611,69 @@ _dodge(void *data)
 }
 
 static Eina_Bool
+_sobel(void *data)
+{
+   Ephoto_Filter *ef = data;
+   Evas_Coord x, y, w, h;
+   int i, j, passes = 0;
+   unsigned int *p;
+   float sobx[3][3] = {{-1, 0, 1},
+   {-2, 0, 2},
+   {-1, 0, 1}};
+   float soby[3][3] = {{-1, -2, -1},
+   {0, 0, 0},
+   {1, 2, 1}};
+
+   w = ef->w;
+   h = ef->h;
+   for (y = ef->pos; y < h; y++)
+ {
+p = ef->im_data_new + (y * w);
+for (x = 0; x < w; x++)
+  {
+ int pval = 0, a, r, g, b;
+ double hpval = 0.0, vpval = 0.0;
+ if (y > 0 && x > 0 && y < (h - 2) && x < (w - 2))
+   {
+  for (i = -1; i <= 1; i++)
+{
+   for (j = -1; j <= 1; j++)
+ {
+int index, pix;
+ 
+index = (y + i) * w + x + j;
+pix = ef->im_data[index];
+hpval += pix * sobx[i+1][j+1];
+vpval += pix * soby[i+1][j+1];
+ }
+}
+   }
+ pval = abs(hpval) + abs(vpval);
+ *p = pval;
+ b = (int) ((*p) & 0xff);
+ g = (int) ((*p >> 8) & 0xff);
+ r = (int) ((*p >> 16) & 0xff);
+ a = (int) ((*p >> 24) & 0xff);
+ b = _normalize_color(b);
+ g = _normalize_color(g);
+ r = _normalize_color(r);
+ a = _normalize_color(a);
+ *p = (a << 24) | (r << 16) | (g << 8) | b;
+ p++;
+  }
+passes++;
+if (passes == 500)
+  {
+ ef->pos = y++;
+ return EINA_TRUE;
+  }
+ }
+   _idler_finishing_cb(ef, EINA_FALSE);
+
+   return EINA_FALSE;
+}
+
+static Eina_Bool
 _histogram_eq(void *data)
 {
Ephoto_Filter *ef = data;
@@ -760,7 +824,7 @@ ephoto_filter_cartoon(Evas_Object *main, Evas_Object *image)
Ephoto_Filter *ef = _initialize_filter(EPHOTO_IMAGE_FILTER_CARTOON,
main, image);
 
-   ef->rad = 5;
+   ef->rad = 9;
ef->drad = 5.0;
ef->qpos = 0;
ef->qcount = 1;
@@ -793,6 +857,20 @@ void ephoto_filter_sketch(Evas_Object *main, Evas_Object 
*image)
ef->idler = ecore_idler_add(_grayscale, ef);  
 }
 
+void ephoto_filter_edge(Evas_Object *main, Evas_Object *image)
+{
+   Ephoto_Filter *ef = _initialize_filter(EPHOTO_IMAGE_FILTER_SOBEL,
+   main, image);
+
+   ef->rad = 3;
+   ef->qpos = 0;
+   ef->qcount = 2;
+   ef->queue = eina_list_append(ef->queue, _grayscale);
+   ef->queue = eina_list_append(ef->queue, _sobel);
+   ef->popup = _processing(main);
+   ef->idler = ecore_idler_add(_blur, ef);
+}
+
 void
 ephoto_filter_histogram_eq(Evas_Object *main, Evas_Object *image)
 {
diff --git a/src/bin/ephoto_single_browser.c b/src/bin/ephoto_single_browser.c
index

[EGIT] [core/efl] master 01/01: efl readme - add platfomr support info there and openbsd not supported

2016-06-13 Thread Carsten Haitzler

raster pushed a commit to branch master.

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

commit d8eae1a1aac6fd29c5c6fda029f9383dbff6f2f8
Author: Carsten Haitzler (Rasterman) 
Date:   Tue Jun 14 10:46:44 2016 +0900

efl readme - add platfomr support info there and openbsd not supported

add some info on platform support in readme and note than openbsd is
not supported.
---
 README | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/README b/README
index 52c8426..fc874b3 100644
--- a/README
+++ b/README
@@ -26,6 +26,17 @@ For more documentation please see:
 
 http://www.enlightenment.org/p.php?p=docs
 
+PLATFORMS
+-
+
+EFL is primarily developerd on Linux (GNU/Linux) and should work on
+most distributions as long as dependencies are provided. It has been
+compiled and run also on Windows (using MINGW32 - please see
+http://www.winbuilds.org ), Mac OS X, FreeBSD and NetBSD. Due to
+serious bugs in OpenBSD, EFL cannot be compiled ro used there. Please
+see:
+
+https://www.mail-archive.com/search?l=m...@openbsd.org=subject:%22SIGCHLD+and+libpthread.so%22=newest=1
 
 
 COMPONENTS

--

[E-devel] efl + openbsd == not supported

2016-06-13 Thread The Rasterman

so after some debugging with al poole regarding openbsd it has come to my
attention (thanks al!) that:

https://www.mail-archive.com/search?l=m...@openbsd.org=subject:%22SIGCHLD+and+libpthread.so%22=newest=1

basiclly put we can't use sigchld AND threads on openbsd in the same process...
which basically rules out EFL.

it seems openbsd is just broken using SIGCHLD at least as a real posix +
pthread implementation of unix:

https://www.openbsd.org/papers/eurobsd2012/guenther-rthreads/slide002.html

so ... in general it seems openbsd still suffers from this (al poole has found
that we just are missing sigchlds in both edje_cc from the embryo_cc processes
as well as in enlightenment e.g. with tempget and other slave processes)

so i'm going to take the step of declaring openbsd "not supported" until such a
time as it no longer exhibits such bugs. feel free to point out that this
feedback is incorrect and the bug has been fixed. i can only find traces of the
bug being reported and no information on it being fixed.

--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

79 matches

Mail list logo