Re: [E-devel] Adding support for head mounted displays.

[Andrew Williams]

Yup that's right. Actually I've yet to find out if it works on my Mac Pro...

Andy
On Wed, 6 Jan 2016 at 01:48, David Seikel  wrote:

> On Tue, 05 Jan 2016 23:56:21 + Andrew Williams
>  wrote:
>
> > Exciting stuff! Just unboxing my rift - will be happy to help test
> > where I can :-D
>
> Cool. I'm guessing you got a second hand Dk2?  The pre orders for the
> CV1 only open up in 14 hours.
>
> > Andy
> > On Tue, 5 Jan 2016 at 21:45, David Seikel  wrote:
> >
> > > On Tue, 5 Jan 2016 11:47:09 -0800 Cedric BAIL 
> > > wrote:
> > > > >> >> So basically, get the mode info and check the "flags" of the
> > > > >> >> mode struct for supported layouts. Possible values on
> > > > >> >> "flags":
> > > > >> >>
> > > > >> >> #define DRM_MODE_FLAG_3D_MASK
> > > > >> >> (0x1f<<14) #define
> > > > >> >> DRM_MODE_FLAG_3D_NONE (0<<14) #define
> > > > >> >> DRM_MODE_FLAG_3D_FRAME_PACKING(1<<14) #define
> > > > >> >> DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE(2<<14) #define
> > > > >> >> DRM_MODE_FLAG_3D_LINE_ALTERNATIVE (3<<14) #define
> > > > >> >> DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL(4<<14) #define
> > > > >> >> DRM_MODE_FLAG_3D_L_DEPTH  (5<<14) #define
> > > > >> >> DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH(6<<14) #define
> > > > >> >> DRM_MODE_FLAG_3D_TOP_AND_BOTTOM   (7<<14) #define
> > > > >> >> DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF(8<<14)
> > > > >> >>
> > > > >> >> This would/should actually be quite simple to detect in the
> > > > >> >> ecore_drm code as we already fetch mode info for crtcs.
> > > > >> >> Would just be a matter of checking for these flags.
> > > > >> >
> > > > >> > Not quite so correct.  Sure this probably works fine under
> > > > >> > DRM / Wayland, but I mentioned Mac OS X and Windows as well
> > > > >> > as Linux.
> > > > >>
> > > > >> Sure. I defer to your wisdom in those areas ;) I was mearly
> > > > >> stating that (as far as code goes), it would be fairly simple
> > > > >> (wrt libdrm) to add these pieces to ecore_drm.
> > > > >
> > > > > Yep, looks simple enough.  Still wont be useful for Mac and
> > > > > Windows support, but at least that's Linux catered for in the
> > > > > "detect a HMD that wants to be a monitor" stakes.  As I pointed
> > > > > out, not all HMDs present themselves as monitors.
> > > >
> > > > Or Android. Also... it is not that useful on Linux as there is no
> > > > support for HMD at the moment and Occulus Rift doesn't seems to
> > > > interested by that.
> > >
> > > Oculus did initially support Linux and Mac, but "paused" support for
> > > them.  Older SDKs still work.  Also, see the bottom of this email.
> > > HTC Vive is a Steam thing, and Steam tries to be cross platform
> > > more or less, but I've not checked that out yet.  I did create a
> > > Steam account to see what I could find there to run on the DK2 I
> > > have, and found stuff that worked fine under Windows at least.
> > > Google Cardboard is obviously an Android thing, but there's
> > > software that uses that protocol at the end of a network link,
> > > driven from Windows.
> > >
> > > > Also the situation is more complex that I think it would be.
> > > > There is actually 2 differents content that are streamed to an
> > > > HMD. 360 view (either spherical or cylinder mapped) and
> > > > stereoscopic view. Of course, some HMD support one or the other
> > > > or both, enjoy !
> > >
> > > It's way worse than that.  VR movies are all over the place as far
> > > as formats are concerned.  Each of those DRM_MODE_FLAGS DH mentioned
> > > before, plus a few more, have been used to make movies.  Movie
> > > players have a dozen or more complex controls to try to sort out
> > > what to do for any particular movie.  Some movies bypass the entire
> > > problem and come embedded inside their own viewer, or rather three
> > > of them to support the major HMDs.
> > >
> > > > But that's only the beginning of the trouble, each HMD has
> > > > different lense which means they need different transformation
> > > > (and I have not gotten the confirmation that you could write one
> > > > filter that cover every HMD).
> > >
> > > I doubt if you could get a generic filter.  One of the big issues is
> > > support for people that have to wear glasses, I'm one of those.
> > > There's various options for dealing with that used by various
> > > manufacturers.  This includes providing standard frames for
> > > optometrists to fit prescription lenses into.  Each individuals
> > > lenses can be custom!
> > >
> > > The Oculus Rift DK1 came with three different pairs of lenses to
> > > help the glasses wearers, the DK2 cut that down to two.  Some allow
> > > similar dioptric adjustment as is in top end camera viewfinders.  I
> > > think the CV1 just goes with "give 'em a bit more room for their
> > > specs", and maybe a standardised frame?  Hopefully I'll have mine
> > > shortly after my birthday, and then go visit my eye doctor.
> > >
> > > > Now, my understanding is that there i

Re: [E-devel] Issues with Ector and shipped headers

[Jean-Philippe André]

On 6 January 2016 at 15:48, Cedric BAIL  wrote:

> On Jan 5, 2016 20:45, "Jean-Philippe André"  wrote:
> >
> > Hi Tom & Cedric,
> >
> > On 6 January 2016 at 01:01, Tom Hacohen  wrote:
> >
> > > Hey,
> > >
> > > ABI report generation is failing due to issues with Ector. I think I
> can
> > > hack around them for the purpose of the report, but these are real
> > > issues that need fixing./
> > >
> >
> > Thanks for the report.
> >
> >
> > > The first obvious failure was the ector gl headers not being shipped.
> > > This sounds like internal engine stuff to me, are they even supposed to
> > > be shipped? I added a few headers to the list of installed headers
> > > because Ector_Gl.h is shipped, but I'm not even sure this one should be
> > > there.
> > >
> > > Even worse though is the fact that ector_surface.h is shipped and
> > > depends on ector_buffer.h which is intentionally not shipped (put in
> > > EXTRA_DIST).
> >
> >
> > Not a conscious choice on my part.
> > ector_buffer belongs to the rest of the headers, wherever they go.
> >
> >
> > > I don't know what to do with that. Should ector_surface.h
> > > not be shipped? Should ector_buffer.h be? Should something else happen
> > > there?
> > >
> > > Please, someone who knows this code (cedric?) fix it.
> > >
> >
> > I don't think any Ector APIs should be "public".
> > This means no headers should be installed.
> >
> > evas_ector_buffer.h also shouldn't be installed.
> >
> > Currently Ector.h is protected by EFL_BETA_API_SUPPORT while the others
> > (Ector_GL, Ector_Cairo, ...) are not, but they should be.
> > Eventually Ector may become stable, but at this moment it clearly is not
> > meant to be used outside of Evas.
> >
> > Cedric, what do you think?
>
> Indeed, I didn't notice that this header where not in beta. They
> definitively should ! As for installing them,  it's just feel better to get
> that right from the beginning I think, but at the same time you're right on
> how useful they are today. So I don't know.
>

I have added the BETA ifdef and removed the Ector header files from the
installed list.
Feel free to revert if you disagree with this decision.

-- 
Jean-Philippe André
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Adding support for head mounted displays.

[David Seikel]

On Wed, 06 Jan 2016 08:45:00 + Andrew Williams
 wrote:

> Yup that's right. Actually I've yet to find out if it works on my Mac
> Pro...

Good luck, the DK2 can be tricky to get going the first time.
Especially the one I was using, second hand, no manual in the box.  On
the other hand, it's a development kit, I wasn't expecting a manual.
Only found it on the web after I figured things out.

I have a Mac Mini that the DK2 should work on in theory, but I would
need a mini DisplayPort to HDMI adapter to find out.  The company
supplying me with the DK2 wanted me to concentrate on Windows, so I
never bothered testing on Mac.  I will with my CV1, that's what it is
for, cross platform HMD development.  That's what the Mac Mini is for,
cross platform virtual world development.

Hope you get your VR legs quick.  Keep someone nearby to help out and
point you at the bucket until you get used to it.  Unless you have iron
guts like me, then just be careful you don't manage to wrap the cable
around your neck.  A proper Unix beard like mine helps, I think that's
what they are for, and why we spend decades growing a decent neck
protector, to be ready for HMDs.

Welcome to VR Andy.  Don't hit the monsters too hard, or they'll shatter
like glass, and you'll suddenly find you need a new monitor.  Not to
mention the blood all over your keyboard.  Hint, it's yours, not the
monsters, you may need medical attention if this happens.  Have lots of
fun.  B-)

> Andy
> On Wed, 6 Jan 2016 at 01:48, David Seikel  wrote:
> 
> > On Tue, 05 Jan 2016 23:56:21 + Andrew Williams
> >  wrote:
> >
> > > Exciting stuff! Just unboxing my rift - will be happy to help test
> > > where I can :-D
> >
> > Cool. I'm guessing you got a second hand Dk2?  The pre orders for
> > the CV1 only open up in 14 hours.
> >
> > > Andy
> > > On Tue, 5 Jan 2016 at 21:45, David Seikel 
> > > wrote:
> > >
> > > > On Tue, 5 Jan 2016 11:47:09 -0800 Cedric BAIL
> > > >  wrote:
> > > > > >> >> So basically, get the mode info and check the "flags"
> > > > > >> >> of the mode struct for supported layouts. Possible
> > > > > >> >> values on "flags":
> > > > > >> >>
> > > > > >> >> #define DRM_MODE_FLAG_3D_MASK
> > > > > >> >> (0x1f<<14) #define
> > > > > >> >> DRM_MODE_FLAG_3D_NONE (0<<14)
> > > > > >> >> #define DRM_MODE_FLAG_3D_FRAME_PACKING
> > > > > >> >> (1<<14) #define
> > > > > >> >> DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE(2<<14)
> > > > > >> >> #define DRM_MODE_FLAG_3D_LINE_ALTERNATIVE (3<<14)
> > > > > >> >> #define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL
> > > > > >> >> (4<<14) #define DRM_MODE_FLAG_3D_L_DEPTH
> > > > > >> >> (5<<14) #define
> > > > > >> >> DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH(6<<14)
> > > > > >> >> #define DRM_MODE_FLAG_3D_TOP_AND_BOTTOM   (7<<14)
> > > > > >> >> #define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
> > > > > >> >> (8<<14)
> > > > > >> >>
> > > > > >> >> This would/should actually be quite simple to detect in
> > > > > >> >> the ecore_drm code as we already fetch mode info for
> > > > > >> >> crtcs. Would just be a matter of checking for these
> > > > > >> >> flags.
> > > > > >> >
> > > > > >> > Not quite so correct.  Sure this probably works fine
> > > > > >> > under DRM / Wayland, but I mentioned Mac OS X and
> > > > > >> > Windows as well as Linux.
> > > > > >>
> > > > > >> Sure. I defer to your wisdom in those areas ;) I was mearly
> > > > > >> stating that (as far as code goes), it would be fairly
> > > > > >> simple (wrt libdrm) to add these pieces to ecore_drm.
> > > > > >
> > > > > > Yep, looks simple enough.  Still wont be useful for Mac and
> > > > > > Windows support, but at least that's Linux catered for in
> > > > > > the "detect a HMD that wants to be a monitor" stakes.  As I
> > > > > > pointed out, not all HMDs present themselves as monitors.
> > > > >
> > > > > Or Android. Also... it is not that useful on Linux as there
> > > > > is no support for HMD at the moment and Occulus Rift doesn't
> > > > > seems to interested by that.
> > > >
> > > > Oculus did initially support Linux and Mac, but "paused"
> > > > support for them.  Older SDKs still work.  Also, see the bottom
> > > > of this email. HTC Vive is a Steam thing, and Steam tries to be
> > > > cross platform more or less, but I've not checked that out
> > > > yet.  I did create a Steam account to see what I could find
> > > > there to run on the DK2 I have, and found stuff that worked
> > > > fine under Windows at least. Google Cardboard is obviously an
> > > > Android thing, but there's software that uses that protocol at
> > > > the end of a network link, driven from Windows.
> > > >
> > > > > Also the situation is more complex that I think it would be.
> > > > > There is actually 2 differents content that are streamed to an
> > > > > HMD. 360 view (either spherical or cylinder mapped) and
> > > > > stereoscopic view. Of course, some HMD support one or the
> > > > > other or both, enjoy !
> > > >
> > > > It's way worse than that.  VR m

Re: [E-devel] Issues with Ector and shipped headers

[Tom Hacohen]

On 06/01/16 08:56, Jean-Philippe André wrote:
> On 6 January 2016 at 15:48, Cedric BAIL  wrote:
>
>> On Jan 5, 2016 20:45, "Jean-Philippe André"  wrote:
>>>
>>> Hi Tom & Cedric,
>>>
>>> On 6 January 2016 at 01:01, Tom Hacohen  wrote:
>>>
 Hey,

 ABI report generation is failing due to issues with Ector. I think I
>> can
 hack around them for the purpose of the report, but these are real
 issues that need fixing./

>>>
>>> Thanks for the report.
>>>
>>>
 The first obvious failure was the ector gl headers not being shipped.
 This sounds like internal engine stuff to me, are they even supposed to
 be shipped? I added a few headers to the list of installed headers
 because Ector_Gl.h is shipped, but I'm not even sure this one should be
 there.

 Even worse though is the fact that ector_surface.h is shipped and
 depends on ector_buffer.h which is intentionally not shipped (put in
 EXTRA_DIST).
>>>
>>>
>>> Not a conscious choice on my part.
>>> ector_buffer belongs to the rest of the headers, wherever they go.
>>>
>>>
 I don't know what to do with that. Should ector_surface.h
 not be shipped? Should ector_buffer.h be? Should something else happen
 there?

 Please, someone who knows this code (cedric?) fix it.

>>>
>>> I don't think any Ector APIs should be "public".
>>> This means no headers should be installed.
>>>
>>> evas_ector_buffer.h also shouldn't be installed.
>>>
>>> Currently Ector.h is protected by EFL_BETA_API_SUPPORT while the others
>>> (Ector_GL, Ector_Cairo, ...) are not, but they should be.
>>> Eventually Ector may become stable, but at this moment it clearly is not
>>> meant to be used outside of Evas.
>>>
>>> Cedric, what do you think?
>>
>> Indeed, I didn't notice that this header where not in beta. They
>> definitively should ! As for installing them,  it's just feel better to get
>> that right from the beginning I think, but at the same time you're right on
>> how useful they are today. So I don't know.
>>
>
> I have added the BETA ifdef and removed the Ector header files from the
> installed list.
> Feel free to revert if you disagree with this decision.
>

Everything is fixed. Thanks.

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

Re: [E-devel] Probie proposal: conr2d (Jee-Yong Um)

[The Rasterman]

On Wed, 6 Jan 2016 15:04:37 +0900 Jean-Philippe André  said:

> Hello,
> 
> 
> I would like to propose a new candidate for probie access: Jee-Yong Um.
> 
> Also known as conr2d, Jee-Yong has recently been sending a series of
> quality patches for EFL and Elementary, updating them quickly in response
> to review comments on Phab.
> 
> He may be quite new to EFL and upstream in particular, he tackles non
> trivial issues in Edje, preparing the ground for a higher quality API in
> Elementary, including the theme API (size_class, color_class, etc...).
> 
> 
> He still has a couple of patches pending on Phab, and I believe a probie
> access would help him work more efficiently.
> 
> 
> Any objections?

+1

> 
> Best regards,
> 
> -- 
> Jean-Philippe André
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


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


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

Re: [E-devel] Probie proposal: conr2d (Jee-Yong Um)

[Kim Shinwoo]

+1 :]
2016. 1. 6. 오후 7:20에 "Carsten Haitzler" 님이 작성:

> On Wed, 6 Jan 2016 15:04:37 +0900 Jean-Philippe André 
> said:
>
> > Hello,
> >
> >
> > I would like to propose a new candidate for probie access: Jee-Yong Um.
> >
> > Also known as conr2d, Jee-Yong has recently been sending a series of
> > quality patches for EFL and Elementary, updating them quickly in response
> > to review comments on Phab.
> >
> > He may be quite new to EFL and upstream in particular, he tackles non
> > trivial issues in Edje, preparing the ground for a higher quality API in
> > Elementary, including the theme API (size_class, color_class, etc...).
> >
> >
> > He still has a couple of patches pending on Phab, and I believe a probie
> > access would help him work more efficiently.
> >
> >
> > Any objections?
>
> +1
>
> >
> > Best regards,
> >
> > --
> > Jean-Philippe André
> >
> --
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
>
> --
> ___
> 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] Probie proposal: conr2d (Jee-Yong Um)

[Hermet Park]

 +1
  
Regards, Hermet
  
-Original Message-
From: "Kim Shinwoo" 
To: "Enlightenment developer 
list"; 
Cc: 
Sent: 2016-01-06 (수) 21:24:59
Subject: Re: [E-devel] Probie proposal: conr2d (Jee-Yong Um)
 
+1 :]
2016. 1. 6. 오후 7:20에 "Carsten Haitzler" 님이 작성:

> On Wed, 6 Jan 2016 15:04:37 +0900 Jean-Philippe André 

> said:
>
> > Hello,
> >
> >
> > I would like to propose a new candidate for probie access: Jee-Yong 
Um.
> >
> > Also known as conr2d, Jee-Yong has recently been sending a series of
> > quality patches for EFL and Elementary, updating them quickly in 
response
> > to review comments on Phab.
> >
> > He may be quite new to EFL and upstream in particular, he tackles non
> > trivial issues in Edje, preparing the ground for a higher quality API 
in
> > Elementary, including the theme API (size_class, color_class, etc...).
> >
> >
> > He still has a couple of patches pending on Phab, and I believe a 
probie
> > access would help him work more efficiently.
> >
> >
> > Any objections?
>
> +1
>
> >
> > Best regards,
> >
> > --
> > Jean-Philippe André
> >
> 
--
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
>
> 
--
> ___
> 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
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL + Elementary ABI report v1.17.0 alpha1

[Stefan Schmidt]

Hello.

On 05/01/16 17:05, Tom Hacohen wrote:
> Hey,
>
> Here again, the new EFL + Elementary ABI reports.
>
> As usual:
> https://devs.enlightenment.org/~tasn/abi/

My review for EFL. Happy about every other review or comment here.

Ignoring the unstable EO APIs as well as ector which is marked as 
unstable we have still a big number of new APIs:

Ecore_Evas.h
ecore_evas_cocoa_window_get ( Ecore_Evas const* ee )
ecore_evas_wayland_window_get2 ( Ecore_Evas const* ee )

Ecore_Wl2.h
ecore_wl2_display_compositor_version_get ( Ecore_Wl2_Display* disp )
ecore_wl2_display_connect ( char const* name )
ecore_wl2_display_create ( char const* name )
ecore_wl2_display_destroy ( Ecore_Wl2_Display* display )
ecore_wl2_display_disconnect ( Ecore_Wl2_Display* display )
ecore_wl2_display_get ( Ecore_Wl2_Display* display )
ecore_wl2_display_globals_get ( Ecore_Wl2_Display* display )
ecore_wl2_display_registry_get ( Ecore_Wl2_Display* display )
ecore_wl2_display_screen_size_get ( Ecore_Wl2_Display* display, int* w, 
int* h )
ecore_wl2_display_shm_get ( Ecore_Wl2_Display* display )
ecore_wl2_display_terminate ( Ecore_Wl2_Display* display )
ecore_wl2_display_window_find ( Ecore_Wl2_Display* display, unsigned int 
id )
ecore_wl2_dnd_drag_end ( Ecore_Wl2_Input* input )
ecore_wl2_dnd_drag_get ( Ecore_Wl2_Input* input, char const* type )
ecore_wl2_dnd_drag_start ( Ecore_Wl2_Input* input, Ecore_Wl2_Window* 
window, Ecore_Wl2_Window* drag_window )
ecore_wl2_dnd_drag_types_set ( Ecore_Wl2_Input* input, char const** types )
ecore_wl2_dnd_selection_clear ( Ecore_Wl2_Input* input )
ecore_wl2_dnd_selection_get ( Ecore_Wl2_Input* input, char const* type )
ecore_wl2_dnd_selection_owner_has ( Ecore_Wl2_Input* input )
ecore_wl2_dnd_selection_set ( Ecore_Wl2_Input* input, char const** types )
ECORE_WL2_EVENT_DATA_SOURCE_CANCELLED [data]
ECORE_WL2_EVENT_DATA_SOURCE_SEND [data]
ECORE_WL2_EVENT_DATA_SOURCE_TARGET [data]
ECORE_WL2_EVENT_DND_DROP [data]
ECORE_WL2_EVENT_DND_END [data]
ECORE_WL2_EVENT_DND_ENTER [data]
ECORE_WL2_EVENT_DND_LEAVE [data]
ECORE_WL2_EVENT_DND_MOTION [data]
ECORE_WL2_EVENT_FOCUS_IN [data]
ECORE_WL2_EVENT_FOCUS_OUT [data]
ECORE_WL2_EVENT_GLOBAL_ADDED [data]
ECORE_WL2_EVENT_GLOBAL_REMOVED [data]
ECORE_WL2_EVENT_SELECTION_DATA_READY [data]
ECORE_WL2_EVENT_SYNC_DONE [data]
ECORE_WL2_EVENT_WINDOW_CONFIGURE [data]
ecore_wl2_init ( )
ecore_wl2_input_seat_get ( Ecore_Wl2_Input* input )
ecore_wl2_input_ungrab ( Ecore_Wl2_Input* input )
ecore_wl2_keyboard_get ( Ecore_Wl2_Seat* seat )
ecore_wl2_keyboard_repeat_info_set ( Ecore_Wl2_Keyboard* kbd, double 
rate, double delay )
ecore_wl2_keyboard_resource_create ( Ecore_Wl2_Keyboard* kbd, struct 
wl_client* client, struct wl_keyboard_interface const* implementation, 
int version, uint32_t id )
ecore_wl2_output_dpi_get ( Ecore_Wl2_Output* output )
ecore_wl2_pointer_get ( Ecore_Wl2_Seat* seat )
ecore_wl2_pointer_resource_create ( Ecore_Wl2_Pointer* ptr, struct 
wl_client* client, struct wl_pointer_interface const* implementation, 
int version, uint32_t id )
ecore_wl2_seat_capabilities_send ( Ecore_Wl2_Seat* seat, enum 
wl_seat_capability caps )
ecore_wl2_seat_create ( Ecore_Wl2_Display* display, char const* name, 
struct wl_seat_interface const* implementation, int version, 
Ecore_Wl2_Bind_Cb bind_cb, Ecore_Wl2_Unbind_Cb unbind_cb )
ecore_wl2_seat_destroy ( Ecore_Wl2_Seat* seat )
ecore_wl2_seat_pointer_release ( Ecore_Wl2_Seat* seat )
ecore_wl2_shutdown ( )
ecore_wl2_subsurface_del ( Ecore_Wl2_Subsurface* subsurface )
ecore_wl2_subsurface_new ( Ecore_Wl2_Window* window )
ecore_wl2_subsurface_opaque_region_set ( Ecore_Wl2_Subsurface* 
subsurface, int x, int y, int w, int h )
ecore_wl2_subsurface_place_above ( Ecore_Wl2_Subsurface* subsurface, 
struct wl_surface* surface )
ecore_wl2_subsurface_place_below ( Ecore_Wl2_Subsurface* subsurface, 
struct wl_surface* surface )
ecore_wl2_subsurface_position_get ( Ecore_Wl2_Subsurface* subsurface, 
int* x, int* y )
ecore_wl2_subsurface_position_set ( Ecore_Wl2_Subsurface* subsurface, 
int x, int y )
ecore_wl2_subsurface_surface_get ( Ecore_Wl2_Subsurface* subsurface )
ecore_wl2_subsurface_sync_set ( Ecore_Wl2_Subsurface* subsurface, 
Eina_Bool sync )
ecore_wl2_window_alpha_get ( Ecore_Wl2_Window* window )
ecore_wl2_window_alpha_set ( Ecore_Wl2_Window* window, Eina_Bool alpha )
ecore_wl2_window_class_set ( Ecore_Wl2_Window* window, char const* clas )
ecore_wl2_window_cursor_from_name_set ( Ecore_Wl2_Window* window, char 
const* cursor )
ecore_wl2_window_display_get ( Ecore_Wl2_Window const* window )
ecore_wl2_window_free ( Ecore_Wl2_Window* window )
ecore_wl2_window_fullscreen_get ( Ecore_Wl2_Window* window )
ecore_wl2_window_fullscreen_set ( Ecore_Wl2_Window* window, Eina_Bool 
fullscreen )
ecore_wl2_window_geometry_get ( Ecore_Wl2_Window* window, int* x, int* 
y, int* w, int* h )
ecore_wl2_window_geometry_set ( Ecore_Wl2_Window* window, int x, int y, 
int w, int h )
ecore_wl2_window_hide ( Ecore_Wl2_Window* window )
ecore_wl2_window_iconified_get (

Re: [E-devel] EFL + Elementary ABI report v1.17.0 alpha1

[Tom Hacohen]

On 06/01/16 15:52, Stefan Schmidt wrote:
> Hello.
>
> On 05/01/16 17:05, Tom Hacohen wrote:
>> Hey,
>>
>> Here again, the new EFL + Elementary ABI reports.
>>
>> As usual:
>> https://devs.enlightenment.org/~tasn/abi/
>
> My review for EFL. Happy about every other review or comment here.
>
> Ignoring the unstable EO APIs as well as ector which is marked as
> unstable we have still a big number of new APIs:
>
> Ecore_Evas.h
> ecore_evas_cocoa_window_get ( Ecore_Evas const* ee )
> ecore_evas_wayland_window_get2 ( Ecore_Evas const* ee )
>
> Ecore_Wl2.h
> ecore_wl2_display_compositor_version_get ( Ecore_Wl2_Display* disp )
> ecore_wl2_display_connect ( char const* name )
> ecore_wl2_display_create ( char const* name )
> ecore_wl2_display_destroy ( Ecore_Wl2_Display* display )
> ecore_wl2_display_disconnect ( Ecore_Wl2_Display* display )
> ecore_wl2_display_get ( Ecore_Wl2_Display* display )
> ecore_wl2_display_globals_get ( Ecore_Wl2_Display* display )
> ecore_wl2_display_registry_get ( Ecore_Wl2_Display* display )
> ecore_wl2_display_screen_size_get ( Ecore_Wl2_Display* display, int* w,
> int* h )
> ecore_wl2_display_shm_get ( Ecore_Wl2_Display* display )
> ecore_wl2_display_terminate ( Ecore_Wl2_Display* display )
> ecore_wl2_display_window_find ( Ecore_Wl2_Display* display, unsigned int
> id )
> ecore_wl2_dnd_drag_end ( Ecore_Wl2_Input* input )
> ecore_wl2_dnd_drag_get ( Ecore_Wl2_Input* input, char const* type )
> ecore_wl2_dnd_drag_start ( Ecore_Wl2_Input* input, Ecore_Wl2_Window*
> window, Ecore_Wl2_Window* drag_window )
> ecore_wl2_dnd_drag_types_set ( Ecore_Wl2_Input* input, char const** types )
> ecore_wl2_dnd_selection_clear ( Ecore_Wl2_Input* input )
> ecore_wl2_dnd_selection_get ( Ecore_Wl2_Input* input, char const* type )
> ecore_wl2_dnd_selection_owner_has ( Ecore_Wl2_Input* input )
> ecore_wl2_dnd_selection_set ( Ecore_Wl2_Input* input, char const** types )
> ECORE_WL2_EVENT_DATA_SOURCE_CANCELLED [data]
> ECORE_WL2_EVENT_DATA_SOURCE_SEND [data]
> ECORE_WL2_EVENT_DATA_SOURCE_TARGET [data]
> ECORE_WL2_EVENT_DND_DROP [data]
> ECORE_WL2_EVENT_DND_END [data]
> ECORE_WL2_EVENT_DND_ENTER [data]
> ECORE_WL2_EVENT_DND_LEAVE [data]
> ECORE_WL2_EVENT_DND_MOTION [data]
> ECORE_WL2_EVENT_FOCUS_IN [data]
> ECORE_WL2_EVENT_FOCUS_OUT [data]
> ECORE_WL2_EVENT_GLOBAL_ADDED [data]
> ECORE_WL2_EVENT_GLOBAL_REMOVED [data]
> ECORE_WL2_EVENT_SELECTION_DATA_READY [data]
> ECORE_WL2_EVENT_SYNC_DONE [data]
> ECORE_WL2_EVENT_WINDOW_CONFIGURE [data]
> ecore_wl2_init ( )
> ecore_wl2_input_seat_get ( Ecore_Wl2_Input* input )
> ecore_wl2_input_ungrab ( Ecore_Wl2_Input* input )
> ecore_wl2_keyboard_get ( Ecore_Wl2_Seat* seat )
> ecore_wl2_keyboard_repeat_info_set ( Ecore_Wl2_Keyboard* kbd, double
> rate, double delay )
> ecore_wl2_keyboard_resource_create ( Ecore_Wl2_Keyboard* kbd, struct
> wl_client* client, struct wl_keyboard_interface const* implementation,
> int version, uint32_t id )
> ecore_wl2_output_dpi_get ( Ecore_Wl2_Output* output )
> ecore_wl2_pointer_get ( Ecore_Wl2_Seat* seat )
> ecore_wl2_pointer_resource_create ( Ecore_Wl2_Pointer* ptr, struct
> wl_client* client, struct wl_pointer_interface const* implementation,
> int version, uint32_t id )
> ecore_wl2_seat_capabilities_send ( Ecore_Wl2_Seat* seat, enum
> wl_seat_capability caps )
> ecore_wl2_seat_create ( Ecore_Wl2_Display* display, char const* name,
> struct wl_seat_interface const* implementation, int version,
> Ecore_Wl2_Bind_Cb bind_cb, Ecore_Wl2_Unbind_Cb unbind_cb )
> ecore_wl2_seat_destroy ( Ecore_Wl2_Seat* seat )
> ecore_wl2_seat_pointer_release ( Ecore_Wl2_Seat* seat )
> ecore_wl2_shutdown ( )
> ecore_wl2_subsurface_del ( Ecore_Wl2_Subsurface* subsurface )
> ecore_wl2_subsurface_new ( Ecore_Wl2_Window* window )
> ecore_wl2_subsurface_opaque_region_set ( Ecore_Wl2_Subsurface*
> subsurface, int x, int y, int w, int h )
> ecore_wl2_subsurface_place_above ( Ecore_Wl2_Subsurface* subsurface,
> struct wl_surface* surface )
> ecore_wl2_subsurface_place_below ( Ecore_Wl2_Subsurface* subsurface,
> struct wl_surface* surface )
> ecore_wl2_subsurface_position_get ( Ecore_Wl2_Subsurface* subsurface,
> int* x, int* y )
> ecore_wl2_subsurface_position_set ( Ecore_Wl2_Subsurface* subsurface,
> int x, int y )
> ecore_wl2_subsurface_surface_get ( Ecore_Wl2_Subsurface* subsurface )
> ecore_wl2_subsurface_sync_set ( Ecore_Wl2_Subsurface* subsurface,
> Eina_Bool sync )
> ecore_wl2_window_alpha_get ( Ecore_Wl2_Window* window )
> ecore_wl2_window_alpha_set ( Ecore_Wl2_Window* window, Eina_Bool alpha )
> ecore_wl2_window_class_set ( Ecore_Wl2_Window* window, char const* clas )
> ecore_wl2_window_cursor_from_name_set ( Ecore_Wl2_Window* window, char
> const* cursor )
> ecore_wl2_window_display_get ( Ecore_Wl2_Window const* window )
> ecore_wl2_window_free ( Ecore_Wl2_Window* window )
> ecore_wl2_window_fullscreen_get ( Ecore_Wl2_Window* window )
> ecore_wl2_window_fullscreen_set ( Ecore_Wl2_Window* window, Eina_Bool
> fullscreen )
> ecore_wl2_window_geometry_get ( Ecore_Wl2

Re: [E-devel] EFL + Elementary ABI report v1.17.0 alpha1

[Stefan Schmidt]

Hello.

On 06/01/16 17:22, Tom Hacohen wrote:
> On 06/01/16 15:52, Stefan Schmidt wrote:
>> Hello.
>>
>> On 05/01/16 17:05, Tom Hacohen wrote:
>>> Hey,
>>>
>>> Here again, the new EFL + Elementary ABI reports.
>>>
>>> As usual:
>>> https://devs.enlightenment.org/~tasn/abi/
>> My review for EFL. Happy about every other review or comment here.
>>
>> Ignoring the unstable EO APIs as well as ector which is marked as
>> unstable we have still a big number of new APIs:
>>
>> Ecore_Evas.h
>> ecore_evas_cocoa_window_get ( Ecore_Evas const* ee )
>> ecore_evas_wayland_window_get2 ( Ecore_Evas const* ee )
>>
>> Ecore_Wl2.h
>> ecore_wl2_display_compositor_version_get ( Ecore_Wl2_Display* disp )
>> ecore_wl2_display_connect ( char const* name )
>> ecore_wl2_display_create ( char const* name )
>> ecore_wl2_display_destroy ( Ecore_Wl2_Display* display )
>> ecore_wl2_display_disconnect ( Ecore_Wl2_Display* display )
>> ecore_wl2_display_get ( Ecore_Wl2_Display* display )
>> ecore_wl2_display_globals_get ( Ecore_Wl2_Display* display )
>> ecore_wl2_display_registry_get ( Ecore_Wl2_Display* display )
>> ecore_wl2_display_screen_size_get ( Ecore_Wl2_Display* display, int* w,
>> int* h )
>> ecore_wl2_display_shm_get ( Ecore_Wl2_Display* display )
>> ecore_wl2_display_terminate ( Ecore_Wl2_Display* display )
>> ecore_wl2_display_window_find ( Ecore_Wl2_Display* display, unsigned int
>> id )
>> ecore_wl2_dnd_drag_end ( Ecore_Wl2_Input* input )
>> ecore_wl2_dnd_drag_get ( Ecore_Wl2_Input* input, char const* type )
>> ecore_wl2_dnd_drag_start ( Ecore_Wl2_Input* input, Ecore_Wl2_Window*
>> window, Ecore_Wl2_Window* drag_window )
>> ecore_wl2_dnd_drag_types_set ( Ecore_Wl2_Input* input, char const** types )
>> ecore_wl2_dnd_selection_clear ( Ecore_Wl2_Input* input )
>> ecore_wl2_dnd_selection_get ( Ecore_Wl2_Input* input, char const* type )
>> ecore_wl2_dnd_selection_owner_has ( Ecore_Wl2_Input* input )
>> ecore_wl2_dnd_selection_set ( Ecore_Wl2_Input* input, char const** types )
>> ECORE_WL2_EVENT_DATA_SOURCE_CANCELLED [data]
>> ECORE_WL2_EVENT_DATA_SOURCE_SEND [data]
>> ECORE_WL2_EVENT_DATA_SOURCE_TARGET [data]
>> ECORE_WL2_EVENT_DND_DROP [data]
>> ECORE_WL2_EVENT_DND_END [data]
>> ECORE_WL2_EVENT_DND_ENTER [data]
>> ECORE_WL2_EVENT_DND_LEAVE [data]
>> ECORE_WL2_EVENT_DND_MOTION [data]
>> ECORE_WL2_EVENT_FOCUS_IN [data]
>> ECORE_WL2_EVENT_FOCUS_OUT [data]
>> ECORE_WL2_EVENT_GLOBAL_ADDED [data]
>> ECORE_WL2_EVENT_GLOBAL_REMOVED [data]
>> ECORE_WL2_EVENT_SELECTION_DATA_READY [data]
>> ECORE_WL2_EVENT_SYNC_DONE [data]
>> ECORE_WL2_EVENT_WINDOW_CONFIGURE [data]
>> ecore_wl2_init ( )
>> ecore_wl2_input_seat_get ( Ecore_Wl2_Input* input )
>> ecore_wl2_input_ungrab ( Ecore_Wl2_Input* input )
>> ecore_wl2_keyboard_get ( Ecore_Wl2_Seat* seat )
>> ecore_wl2_keyboard_repeat_info_set ( Ecore_Wl2_Keyboard* kbd, double
>> rate, double delay )
>> ecore_wl2_keyboard_resource_create ( Ecore_Wl2_Keyboard* kbd, struct
>> wl_client* client, struct wl_keyboard_interface const* implementation,
>> int version, uint32_t id )
>> ecore_wl2_output_dpi_get ( Ecore_Wl2_Output* output )
>> ecore_wl2_pointer_get ( Ecore_Wl2_Seat* seat )
>> ecore_wl2_pointer_resource_create ( Ecore_Wl2_Pointer* ptr, struct
>> wl_client* client, struct wl_pointer_interface const* implementation,
>> int version, uint32_t id )
>> ecore_wl2_seat_capabilities_send ( Ecore_Wl2_Seat* seat, enum
>> wl_seat_capability caps )
>> ecore_wl2_seat_create ( Ecore_Wl2_Display* display, char const* name,
>> struct wl_seat_interface const* implementation, int version,
>> Ecore_Wl2_Bind_Cb bind_cb, Ecore_Wl2_Unbind_Cb unbind_cb )
>> ecore_wl2_seat_destroy ( Ecore_Wl2_Seat* seat )
>> ecore_wl2_seat_pointer_release ( Ecore_Wl2_Seat* seat )
>> ecore_wl2_shutdown ( )
>> ecore_wl2_subsurface_del ( Ecore_Wl2_Subsurface* subsurface )
>> ecore_wl2_subsurface_new ( Ecore_Wl2_Window* window )
>> ecore_wl2_subsurface_opaque_region_set ( Ecore_Wl2_Subsurface*
>> subsurface, int x, int y, int w, int h )
>> ecore_wl2_subsurface_place_above ( Ecore_Wl2_Subsurface* subsurface,
>> struct wl_surface* surface )
>> ecore_wl2_subsurface_place_below ( Ecore_Wl2_Subsurface* subsurface,
>> struct wl_surface* surface )
>> ecore_wl2_subsurface_position_get ( Ecore_Wl2_Subsurface* subsurface,
>> int* x, int* y )
>> ecore_wl2_subsurface_position_set ( Ecore_Wl2_Subsurface* subsurface,
>> int x, int y )
>> ecore_wl2_subsurface_surface_get ( Ecore_Wl2_Subsurface* subsurface )
>> ecore_wl2_subsurface_sync_set ( Ecore_Wl2_Subsurface* subsurface,
>> Eina_Bool sync )
>> ecore_wl2_window_alpha_get ( Ecore_Wl2_Window* window )
>> ecore_wl2_window_alpha_set ( Ecore_Wl2_Window* window, Eina_Bool alpha )
>> ecore_wl2_window_class_set ( Ecore_Wl2_Window* window, char const* clas )
>> ecore_wl2_window_cursor_from_name_set ( Ecore_Wl2_Window* window, char
>> const* cursor )
>> ecore_wl2_window_display_get ( Ecore_Wl2_Window const* window )
>> ecore_wl2_window_free ( Ecore_Wl2_Window* window )
>> ecore_wl2_window_fullscreen_get ( Ecore_Wl2

Re: [E-devel] EFL + Elementary ABI report v1.17.0 alpha1

[Mike Blumenkrantz]

wl2 is indeed not stable and will be marked as such in the very near future
before the final release.

On Wed, Jan 6, 2016 at 11:54 AM Stefan Schmidt 
wrote:

> Hello.
>
> On 06/01/16 17:22, Tom Hacohen wrote:
> > On 06/01/16 15:52, Stefan Schmidt wrote:
> >> Hello.
> >>
> >> On 05/01/16 17:05, Tom Hacohen wrote:
> >>> Hey,
> >>>
> >>> Here again, the new EFL + Elementary ABI reports.
> >>>
> >>> As usual:
> >>> https://devs.enlightenment.org/~tasn/abi/
> >> My review for EFL. Happy about every other review or comment here.
> >>
> >> Ignoring the unstable EO APIs as well as ector which is marked as
> >> unstable we have still a big number of new APIs:
> >>
> >> Ecore_Evas.h
> >> ecore_evas_cocoa_window_get ( Ecore_Evas const* ee )
> >> ecore_evas_wayland_window_get2 ( Ecore_Evas const* ee )
> >>
> >> Ecore_Wl2.h
> >> ecore_wl2_display_compositor_version_get ( Ecore_Wl2_Display* disp )
> >> ecore_wl2_display_connect ( char const* name )
> >> ecore_wl2_display_create ( char const* name )
> >> ecore_wl2_display_destroy ( Ecore_Wl2_Display* display )
> >> ecore_wl2_display_disconnect ( Ecore_Wl2_Display* display )
> >> ecore_wl2_display_get ( Ecore_Wl2_Display* display )
> >> ecore_wl2_display_globals_get ( Ecore_Wl2_Display* display )
> >> ecore_wl2_display_registry_get ( Ecore_Wl2_Display* display )
> >> ecore_wl2_display_screen_size_get ( Ecore_Wl2_Display* display, int* w,
> >> int* h )
> >> ecore_wl2_display_shm_get ( Ecore_Wl2_Display* display )
> >> ecore_wl2_display_terminate ( Ecore_Wl2_Display* display )
> >> ecore_wl2_display_window_find ( Ecore_Wl2_Display* display, unsigned int
> >> id )
> >> ecore_wl2_dnd_drag_end ( Ecore_Wl2_Input* input )
> >> ecore_wl2_dnd_drag_get ( Ecore_Wl2_Input* input, char const* type )
> >> ecore_wl2_dnd_drag_start ( Ecore_Wl2_Input* input, Ecore_Wl2_Window*
> >> window, Ecore_Wl2_Window* drag_window )
> >> ecore_wl2_dnd_drag_types_set ( Ecore_Wl2_Input* input, char const**
> types )
> >> ecore_wl2_dnd_selection_clear ( Ecore_Wl2_Input* input )
> >> ecore_wl2_dnd_selection_get ( Ecore_Wl2_Input* input, char const* type )
> >> ecore_wl2_dnd_selection_owner_has ( Ecore_Wl2_Input* input )
> >> ecore_wl2_dnd_selection_set ( Ecore_Wl2_Input* input, char const**
> types )
> >> ECORE_WL2_EVENT_DATA_SOURCE_CANCELLED [data]
> >> ECORE_WL2_EVENT_DATA_SOURCE_SEND [data]
> >> ECORE_WL2_EVENT_DATA_SOURCE_TARGET [data]
> >> ECORE_WL2_EVENT_DND_DROP [data]
> >> ECORE_WL2_EVENT_DND_END [data]
> >> ECORE_WL2_EVENT_DND_ENTER [data]
> >> ECORE_WL2_EVENT_DND_LEAVE [data]
> >> ECORE_WL2_EVENT_DND_MOTION [data]
> >> ECORE_WL2_EVENT_FOCUS_IN [data]
> >> ECORE_WL2_EVENT_FOCUS_OUT [data]
> >> ECORE_WL2_EVENT_GLOBAL_ADDED [data]
> >> ECORE_WL2_EVENT_GLOBAL_REMOVED [data]
> >> ECORE_WL2_EVENT_SELECTION_DATA_READY [data]
> >> ECORE_WL2_EVENT_SYNC_DONE [data]
> >> ECORE_WL2_EVENT_WINDOW_CONFIGURE [data]
> >> ecore_wl2_init ( )
> >> ecore_wl2_input_seat_get ( Ecore_Wl2_Input* input )
> >> ecore_wl2_input_ungrab ( Ecore_Wl2_Input* input )
> >> ecore_wl2_keyboard_get ( Ecore_Wl2_Seat* seat )
> >> ecore_wl2_keyboard_repeat_info_set ( Ecore_Wl2_Keyboard* kbd, double
> >> rate, double delay )
> >> ecore_wl2_keyboard_resource_create ( Ecore_Wl2_Keyboard* kbd, struct
> >> wl_client* client, struct wl_keyboard_interface const* implementation,
> >> int version, uint32_t id )
> >> ecore_wl2_output_dpi_get ( Ecore_Wl2_Output* output )
> >> ecore_wl2_pointer_get ( Ecore_Wl2_Seat* seat )
> >> ecore_wl2_pointer_resource_create ( Ecore_Wl2_Pointer* ptr, struct
> >> wl_client* client, struct wl_pointer_interface const* implementation,
> >> int version, uint32_t id )
> >> ecore_wl2_seat_capabilities_send ( Ecore_Wl2_Seat* seat, enum
> >> wl_seat_capability caps )
> >> ecore_wl2_seat_create ( Ecore_Wl2_Display* display, char const* name,
> >> struct wl_seat_interface const* implementation, int version,
> >> Ecore_Wl2_Bind_Cb bind_cb, Ecore_Wl2_Unbind_Cb unbind_cb )
> >> ecore_wl2_seat_destroy ( Ecore_Wl2_Seat* seat )
> >> ecore_wl2_seat_pointer_release ( Ecore_Wl2_Seat* seat )
> >> ecore_wl2_shutdown ( )
> >> ecore_wl2_subsurface_del ( Ecore_Wl2_Subsurface* subsurface )
> >> ecore_wl2_subsurface_new ( Ecore_Wl2_Window* window )
> >> ecore_wl2_subsurface_opaque_region_set ( Ecore_Wl2_Subsurface*
> >> subsurface, int x, int y, int w, int h )
> >> ecore_wl2_subsurface_place_above ( Ecore_Wl2_Subsurface* subsurface,
> >> struct wl_surface* surface )
> >> ecore_wl2_subsurface_place_below ( Ecore_Wl2_Subsurface* subsurface,
> >> struct wl_surface* surface )
> >> ecore_wl2_subsurface_position_get ( Ecore_Wl2_Subsurface* subsurface,
> >> int* x, int* y )
> >> ecore_wl2_subsurface_position_set ( Ecore_Wl2_Subsurface* subsurface,
> >> int x, int y )
> >> ecore_wl2_subsurface_surface_get ( Ecore_Wl2_Subsurface* subsurface )
> >> ecore_wl2_subsurface_sync_set ( Ecore_Wl2_Subsurface* subsurface,
> >> Eina_Bool sync )
> >> ecore_wl2_window_alpha_get ( Ecore_Wl2_Window* window )
> >> ecore_wl2_window_alpha_set ( Ecore_Wl2_Window* w

Re: [E-devel] Adding support for head mounted displays.

[David Seikel]

On Tue, 5 Jan 2016 12:06:55 +1000 David Seikel 
wrote:

> Oculus Rift pre orders start in under two days.  I'll jump on that,
> which means I could be getting my Rift by around my birthday at the
> end of January.  B-)

Delivery in March, or April, maybe May.  B-(

> So, my plan is to try out both of those generic open source HMD
> libraries I mentioned before, and check to see if there's others.  If
> one comes out as a clear winner, I'll start with that.  If it's too
> close to call, might be up for some discussion, or we could just
> support both.
> 
> Then I'll hook it up to my SledjHamr EFL based project, see what it
> takes to get it to work.  Again, if the libraries are close, this
> might help shake out quality aspects to help decide.  Armed with this
> experience, and a working example, we can discuss how to get it added
> to EFL.  I'll have working EFL based code by then, so should be simple
> enough to port it to EFL.
> 
> If there's any other EFL devs that are into HMDs and have some, I'd be
> happy to collaborate.  Actually, my default position for anything
> involved in my virtual world work is that it's such a huge project,
> with so many moving parts, that any part I can get others to worry
> about instead of me is something I'm very happy to let others do.  I
> just happen to be well placed right now to be doing this HMD work, and
> eager to get it working with SledjHamr.

-- 
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] EFL + Elementary ABI report v1.17.0 alpha1

[Cedric BAIL]

Hello,

On Wed, Jan 6, 2016 at 7:52 AM, Stefan Schmidt  wrote:
> On 05/01/16 17:05, Tom Hacohen wrote:
>> Here again, the new EFL + Elementary ABI reports.
>>
>> As usual:
>> https://devs.enlightenment.org/~tasn/abi/
>
> My review for EFL. Happy about every other review or comment here.
>
> Ignoring the unstable EO APIs as well as ector which is marked as
> unstable we have still a big number of new APIs:
>
> Ecore_Evas.h
> ecore_evas_cocoa_window_get ( Ecore_Evas const* ee )
> ecore_evas_wayland_window_get2 ( Ecore_Evas const* ee )

get2 ? Is it something we usually do ? Why do we need a get2 ? I mean,
we are in C switching to return a void * is not an ABI break and it
would not create a new function (Arguably all this window_get could
really be just the same function).

> Ecore_Wl2.h
> ecore_wl2_display_compositor_version_get ( Ecore_Wl2_Display* disp )
> ecore_wl2_display_connect ( char const* name )
> ecore_wl2_display_create ( char const* name )
> ecore_wl2_display_destroy ( Ecore_Wl2_Display* display )
> ecore_wl2_display_disconnect ( Ecore_Wl2_Display* display )
> ecore_wl2_display_get ( Ecore_Wl2_Display* display )
> ecore_wl2_display_globals_get ( Ecore_Wl2_Display* display )
> ecore_wl2_display_registry_get ( Ecore_Wl2_Display* display )
> ecore_wl2_display_screen_size_get ( Ecore_Wl2_Display* display, int* w,
> int* h )
> ecore_wl2_display_shm_get ( Ecore_Wl2_Display* display )
> ecore_wl2_display_terminate ( Ecore_Wl2_Display* display )
> ecore_wl2_display_window_find ( Ecore_Wl2_Display* display, unsigned int
> id )
> ecore_wl2_dnd_drag_end ( Ecore_Wl2_Input* input )
> ecore_wl2_dnd_drag_get ( Ecore_Wl2_Input* input, char const* type )
> ecore_wl2_dnd_drag_start ( Ecore_Wl2_Input* input, Ecore_Wl2_Window*
> window, Ecore_Wl2_Window* drag_window )
> ecore_wl2_dnd_drag_types_set ( Ecore_Wl2_Input* input, char const** types )
> ecore_wl2_dnd_selection_clear ( Ecore_Wl2_Input* input )
> ecore_wl2_dnd_selection_get ( Ecore_Wl2_Input* input, char const* type )
> ecore_wl2_dnd_selection_owner_has ( Ecore_Wl2_Input* input )
> ecore_wl2_dnd_selection_set ( Ecore_Wl2_Input* input, char const** types )
> ECORE_WL2_EVENT_DATA_SOURCE_CANCELLED [data]
> ECORE_WL2_EVENT_DATA_SOURCE_SEND [data]
> ECORE_WL2_EVENT_DATA_SOURCE_TARGET [data]
> ECORE_WL2_EVENT_DND_DROP [data]
> ECORE_WL2_EVENT_DND_END [data]
> ECORE_WL2_EVENT_DND_ENTER [data]
> ECORE_WL2_EVENT_DND_LEAVE [data]
> ECORE_WL2_EVENT_DND_MOTION [data]
> ECORE_WL2_EVENT_FOCUS_IN [data]
> ECORE_WL2_EVENT_FOCUS_OUT [data]
> ECORE_WL2_EVENT_GLOBAL_ADDED [data]
> ECORE_WL2_EVENT_GLOBAL_REMOVED [data]
> ECORE_WL2_EVENT_SELECTION_DATA_READY [data]
> ECORE_WL2_EVENT_SYNC_DONE [data]
> ECORE_WL2_EVENT_WINDOW_CONFIGURE [data]
> ecore_wl2_init ( )
> ecore_wl2_input_seat_get ( Ecore_Wl2_Input* input )
> ecore_wl2_input_ungrab ( Ecore_Wl2_Input* input )
> ecore_wl2_keyboard_get ( Ecore_Wl2_Seat* seat )
> ecore_wl2_keyboard_repeat_info_set ( Ecore_Wl2_Keyboard* kbd, double
> rate, double delay )
> ecore_wl2_keyboard_resource_create ( Ecore_Wl2_Keyboard* kbd, struct
> wl_client* client, struct wl_keyboard_interface const* implementation,
> int version, uint32_t id )
> ecore_wl2_output_dpi_get ( Ecore_Wl2_Output* output )
> ecore_wl2_pointer_get ( Ecore_Wl2_Seat* seat )
> ecore_wl2_pointer_resource_create ( Ecore_Wl2_Pointer* ptr, struct
> wl_client* client, struct wl_pointer_interface const* implementation,
> int version, uint32_t id )
> ecore_wl2_seat_capabilities_send ( Ecore_Wl2_Seat* seat, enum
> wl_seat_capability caps )
> ecore_wl2_seat_create ( Ecore_Wl2_Display* display, char const* name,
> struct wl_seat_interface const* implementation, int version,
> Ecore_Wl2_Bind_Cb bind_cb, Ecore_Wl2_Unbind_Cb unbind_cb )
> ecore_wl2_seat_destroy ( Ecore_Wl2_Seat* seat )
> ecore_wl2_seat_pointer_release ( Ecore_Wl2_Seat* seat )
> ecore_wl2_shutdown ( )
> ecore_wl2_subsurface_del ( Ecore_Wl2_Subsurface* subsurface )
> ecore_wl2_subsurface_new ( Ecore_Wl2_Window* window )
> ecore_wl2_subsurface_opaque_region_set ( Ecore_Wl2_Subsurface*
> subsurface, int x, int y, int w, int h )
> ecore_wl2_subsurface_place_above ( Ecore_Wl2_Subsurface* subsurface,
> struct wl_surface* surface )
> ecore_wl2_subsurface_place_below ( Ecore_Wl2_Subsurface* subsurface,
> struct wl_surface* surface )
> ecore_wl2_subsurface_position_get ( Ecore_Wl2_Subsurface* subsurface,
> int* x, int* y )
> ecore_wl2_subsurface_position_set ( Ecore_Wl2_Subsurface* subsurface,
> int x, int y )
> ecore_wl2_subsurface_surface_get ( Ecore_Wl2_Subsurface* subsurface )
> ecore_wl2_subsurface_sync_set ( Ecore_Wl2_Subsurface* subsurface,
> Eina_Bool sync )
> ecore_wl2_window_alpha_get ( Ecore_Wl2_Window* window )
> ecore_wl2_window_alpha_set ( Ecore_Wl2_Window* window, Eina_Bool alpha )
> ecore_wl2_window_class_set ( Ecore_Wl2_Window* window, char const* clas )
> ecore_wl2_window_cursor_from_name_set ( Ecore_Wl2_Window* window, char
> const* cursor )
> ecore_wl2_window_display_get ( Ecore_Wl2_Window const* window )
> ec

Re: [E-devel] EFL + Elementary ABI report v1.17.0 alpha1

[Stefan Schmidt]

Hello.

On 05/01/16 17:05, Tom Hacohen wrote:
> Hey,
>
> Here again, the new EFL + Elementary ABI reports.
>
> As usual:
> https://devs.enlightenment.org/~tasn/abi/
>

Onwards to the Elementary report review. Only very few additions here 
compared to efl. Ignoring the EO changes and other things marked as 
unstable I see the following:

elc_combobox_legacy.h
elm_combobox_add ( Evas_Object* parent )

elm_combobox.eo.legacy.h
elm_combobox_expanded_get ( Elm_Combobox const* obj )
elm_combobox_hover_begin ( Elm_Combobox* obj )
elm_combobox_hover_end ( Elm_Combobox* obj )

elm_config.h
elm_config_context_menu_disabled_get ( )
elm_config_context_menu_disabled_set ( Eina_Bool enabled )
elm_config_profile_derived_add ( char const* profile, char const* 
derive_options )
elm_config_profile_derived_del ( char const* profile )
elm_config_profile_exists ( char const* profile )
elm_config_profile_list_full_get ( )
elm_config_profile_save ( char const* profile )

elm_notify.eo.legacy.h
elm_notify_dismiss ( Elm_Notify* obj )

elm_popup.eo.legacy.h
elm_popup_dismiss ( Elm_Popup* obj )

elm_sys_notify.eo.legacy.h
elm_sys_notify_servers_get ( Elm_Sys_Notify const* obj )
elm_sys_notify_servers_set ( Elm_Sys_Notify* obj, enum 
Elm_Sys_Notify_Server servers )
elm_sys_notify_singleton_get ( )

elm_sys_notify_interface.eo.legacy.h
elm_sys_notify_interface_close ( Elm_Sys_Notify_Interface const* obj, 
unsigned int id )
elm_sys_notify_interface_send ( Elm_Sys_Notify_Interface const* obj, 
unsigned int replaces_id, char const* icon, char const* summary, char 
const* body, enum Elm_Sys_Notify_Urgency urgency, int timeout, 
void(*cb)(void*, unsigned int), void const* cb_data )
elm_sys_notify_interface_simple_send ( Elm_Sys_Notify_Interface const* 
obj, char const* icon, char const* summary, char const* body )

elm_win.eo.legacy.h
elm_win_cocoa_window_get ( Elm_Win const* obj )

elm_win_legacy.h
elm_win_win32_window_get ( Evas_Object const* obj )

Nothing really problematic from my side.

regards
Stefan Schmidt

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

Re: [E-devel] EFL + Elementary ABI report v1.17.0 alpha1

[Tom Hacohen]

On 06/01/16 18:38, Cedric BAIL wrote:
> Hello,
>
> On Wed, Jan 6, 2016 at 7:52 AM, Stefan Schmidt  wrote:
>> On 05/01/16 17:05, Tom Hacohen wrote:
>>> Here again, the new EFL + Elementary ABI reports.
>>>
>>> As usual:
>>> https://devs.enlightenment.org/~tasn/abi/
>>
>> My review for EFL. Happy about every other review or comment here.
>>
>> Ignoring the unstable EO APIs as well as ector which is marked as
>> unstable we have still a big number of new APIs:
>>
>> Ecore_Evas.h
>> ecore_evas_cocoa_window_get ( Ecore_Evas const* ee )
>> ecore_evas_wayland_window_get2 ( Ecore_Evas const* ee )
>
> get2 ? Is it something we usually do ? Why do we need a get2 ? I mean,
> we are in C switching to return a void * is not an ABI break and it
> would not create a new function (Arguably all this window_get could
> really be just the same function).

I missed that one. Also, the namespace seems wrong, it should probably be:

ecore_evas_wayland2_window_get() if not your suggestion (which is better).


>
>> Ecore_Wl2.h
>> ecore_wl2_display_compositor_version_get ( Ecore_Wl2_Display* disp )
>> ecore_wl2_display_connect ( char const* name )
>> ecore_wl2_display_create ( char const* name )
>> ecore_wl2_display_destroy ( Ecore_Wl2_Display* display )
>> ecore_wl2_display_disconnect ( Ecore_Wl2_Display* display )
>> ecore_wl2_display_get ( Ecore_Wl2_Display* display )
>> ecore_wl2_display_globals_get ( Ecore_Wl2_Display* display )
>> ecore_wl2_display_registry_get ( Ecore_Wl2_Display* display )
>> ecore_wl2_display_screen_size_get ( Ecore_Wl2_Display* display, int* w,
>> int* h )
>> ecore_wl2_display_shm_get ( Ecore_Wl2_Display* display )
>> ecore_wl2_display_terminate ( Ecore_Wl2_Display* display )
>> ecore_wl2_display_window_find ( Ecore_Wl2_Display* display, unsigned int
>> id )
>> ecore_wl2_dnd_drag_end ( Ecore_Wl2_Input* input )
>> ecore_wl2_dnd_drag_get ( Ecore_Wl2_Input* input, char const* type )
>> ecore_wl2_dnd_drag_start ( Ecore_Wl2_Input* input, Ecore_Wl2_Window*
>> window, Ecore_Wl2_Window* drag_window )
>> ecore_wl2_dnd_drag_types_set ( Ecore_Wl2_Input* input, char const** types )
>> ecore_wl2_dnd_selection_clear ( Ecore_Wl2_Input* input )
>> ecore_wl2_dnd_selection_get ( Ecore_Wl2_Input* input, char const* type )
>> ecore_wl2_dnd_selection_owner_has ( Ecore_Wl2_Input* input )
>> ecore_wl2_dnd_selection_set ( Ecore_Wl2_Input* input, char const** types )
>> ECORE_WL2_EVENT_DATA_SOURCE_CANCELLED [data]
>> ECORE_WL2_EVENT_DATA_SOURCE_SEND [data]
>> ECORE_WL2_EVENT_DATA_SOURCE_TARGET [data]
>> ECORE_WL2_EVENT_DND_DROP [data]
>> ECORE_WL2_EVENT_DND_END [data]
>> ECORE_WL2_EVENT_DND_ENTER [data]
>> ECORE_WL2_EVENT_DND_LEAVE [data]
>> ECORE_WL2_EVENT_DND_MOTION [data]
>> ECORE_WL2_EVENT_FOCUS_IN [data]
>> ECORE_WL2_EVENT_FOCUS_OUT [data]
>> ECORE_WL2_EVENT_GLOBAL_ADDED [data]
>> ECORE_WL2_EVENT_GLOBAL_REMOVED [data]
>> ECORE_WL2_EVENT_SELECTION_DATA_READY [data]
>> ECORE_WL2_EVENT_SYNC_DONE [data]
>> ECORE_WL2_EVENT_WINDOW_CONFIGURE [data]
>> ecore_wl2_init ( )
>> ecore_wl2_input_seat_get ( Ecore_Wl2_Input* input )
>> ecore_wl2_input_ungrab ( Ecore_Wl2_Input* input )
>> ecore_wl2_keyboard_get ( Ecore_Wl2_Seat* seat )
>> ecore_wl2_keyboard_repeat_info_set ( Ecore_Wl2_Keyboard* kbd, double
>> rate, double delay )
>> ecore_wl2_keyboard_resource_create ( Ecore_Wl2_Keyboard* kbd, struct
>> wl_client* client, struct wl_keyboard_interface const* implementation,
>> int version, uint32_t id )
>> ecore_wl2_output_dpi_get ( Ecore_Wl2_Output* output )
>> ecore_wl2_pointer_get ( Ecore_Wl2_Seat* seat )
>> ecore_wl2_pointer_resource_create ( Ecore_Wl2_Pointer* ptr, struct
>> wl_client* client, struct wl_pointer_interface const* implementation,
>> int version, uint32_t id )
>> ecore_wl2_seat_capabilities_send ( Ecore_Wl2_Seat* seat, enum
>> wl_seat_capability caps )
>> ecore_wl2_seat_create ( Ecore_Wl2_Display* display, char const* name,
>> struct wl_seat_interface const* implementation, int version,
>> Ecore_Wl2_Bind_Cb bind_cb, Ecore_Wl2_Unbind_Cb unbind_cb )
>> ecore_wl2_seat_destroy ( Ecore_Wl2_Seat* seat )
>> ecore_wl2_seat_pointer_release ( Ecore_Wl2_Seat* seat )
>> ecore_wl2_shutdown ( )
>> ecore_wl2_subsurface_del ( Ecore_Wl2_Subsurface* subsurface )
>> ecore_wl2_subsurface_new ( Ecore_Wl2_Window* window )
>> ecore_wl2_subsurface_opaque_region_set ( Ecore_Wl2_Subsurface*
>> subsurface, int x, int y, int w, int h )
>> ecore_wl2_subsurface_place_above ( Ecore_Wl2_Subsurface* subsurface,
>> struct wl_surface* surface )
>> ecore_wl2_subsurface_place_below ( Ecore_Wl2_Subsurface* subsurface,
>> struct wl_surface* surface )
>> ecore_wl2_subsurface_position_get ( Ecore_Wl2_Subsurface* subsurface,
>> int* x, int* y )
>> ecore_wl2_subsurface_position_set ( Ecore_Wl2_Subsurface* subsurface,
>> int x, int y )
>> ecore_wl2_subsurface_surface_get ( Ecore_Wl2_Subsurface* subsurface )
>> ecore_wl2_subsurface_sync_set ( Ecore_Wl2_Subsurface* subsurface,
>> Eina_Bool sync )
>> ecore_wl2_window_alpha_get ( Ecore_Wl2_Window* window )
>> ecore_wl2_w

Re: [E-devel] Probie proposal: conr2d (Jee-Yong Um)

[Mike Blumenkrantz]

Not an objection, but for future cases can some example patches be provided
in the initial mail? Saying "quality patches" is great, but providing 1-2
explicit/noteworthy examples would allow people who aren't as familiar with
the person's work (ie. don't work at Samsung) to form an opinion more
easily.

On Wed, Jan 6, 2016 at 10:22 AM Hermet Park  wrote:

>  +1
>
> Regards, Hermet
>
> -Original Message-
> From: "Kim Shinwoo"
> To: "Enlightenment developer list"&
> lt;enlightenment-devel@lists.sourceforge.net>;
> Cc:
> Sent: 2016-01-06 (수) 21:24:59
> Subject: Re: [E-devel] Probie proposal: conr2d (Jee-Yong Um)
>
> +1 :]
> 2016. 1. 6. 오후 7:20에 "Carsten Haitzler" 님이 작성:
>
> > On Wed, 6 Jan 2016 15:04:37 +0900 Jean-Philippe André &
> lt;j...@videolan.org>
> > said:
> >
> > > Hello,
> > >
> > >
> > > I would like to propose a new candidate for probie access:
> Jee-Yong Um.
> > >
> > > Also known as conr2d, Jee-Yong has recently been sending a
> series of
> > > quality patches for EFL and Elementary, updating them quickly in
> response
> > > to review comments on Phab.
> > >
> > > He may be quite new to EFL and upstream in particular, he
> tackles non
> > > trivial issues in Edje, preparing the ground for a higher
> quality API in
> > > Elementary, including the theme API (size_class, color_class,
> etc...).
> > >
> > >
> > > He still has a couple of patches pending on Phab, and I believe
> a probie
> > > access would help him work more efficiently.
> > >
> > >
> > > Any objections?
> >
> > +1
> >
> > >
> > > Best regards,
> > >
> > > --
> > > Jean-Philippe André
> > >
> >
> --
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >;
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am"
> --
> > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> >
> >
> >
> >
> --
> > ___
> > 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
>
> --
> ___
> 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] Evas 3d, Eina matrix, Ector, etc...

[Cedric BAIL]

Hello,

On Tue, Jan 5, 2016 at 10:04 PM, Jean-Philippe André  wrote:
> Recently a series of patches for Evas 3d and Evas VG have been merged in
> (mostly by Cedric and myself), and add a bunch of new APIs as well as EAPI
> symbols.
>
> I also accepted two patches and forgot to push them yesterday before the
> freeze:
> 1. 996d17bcc5a08e75f evas: Update Ector_Color structure
> 2. d2bb0eefc4a2eb640 Evas 3d: Get hash table of scenes using the given node
> as root.
>
> If you find them not acceptable for this release, please revert (patch 1.
> is probably fine... but see below).
>
>
> None of the Ector APIs are stable.
>
>
> So, this raises a few questions:
> - Should eina_vector{2,3} be static inline in the header instead of EAPI?
> (less symbols)

I think so.

> - Should we even install the Ector headers?
> - Should Ector_Color be Efl.Gfx.Color instead? Or Eina? (I argued myself
> that color belonged to ector, but now I wonder, considering ector is not
> stable)

I have been thinking they should belong to Efl.Gfx.Color in fact as we
do have API to set color in Efl.Gfx and it would make sense to make
this compatible with that structure. I may do that change tomorrow if
nobody raise their voice on the matter.
-- 
Cedric BAIL

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

Re: [E-devel] Probie proposal: conr2d (Jee-Yong Um)

[Jean-Philippe André]

On 7 January 2016 at 03:53, Mike Blumenkrantz <
michael.blumenkra...@gmail.com> wrote:

> Not an objection, but for future cases can some example patches be provided
> in the initial mail? Saying "quality patches" is great, but providing 1-2
> explicit/noteworthy examples would allow people who aren't as familiar with
> the person's work (ie. don't work at Samsung) to form an opinion more
> easily.
>


I thought of doing that, but then... I guess I was too lazy :)

And in particular patches such as:
https://phab.enlightenment.org/D3435
https://phab.enlightenment.org/D3329

And some ongoing work:
https://phab.enlightenment.org/D3458

See https://phab.enlightenment.org/p/conr2d/

:)


>
> On Wed, Jan 6, 2016 at 10:22 AM Hermet Park  wrote:
>
> >  +1
> >
> > Regards, Hermet
> >
> > -Original Message-
> > From: "Kim Shinwoo"
> > To: "Enlightenment developer list"&
> > lt;enlightenment-devel@lists.sourceforge.net>;
> > Cc:
> > Sent: 2016-01-06 (수) 21:24:59
> > Subject: Re: [E-devel] Probie proposal: conr2d (Jee-Yong Um)
> >
> > +1 :]
> > 2016. 1. 6. 오후 7:20에 "Carsten Haitzler" 님이
> 작성:
> >
> > > On Wed, 6 Jan 2016 15:04:37 +0900 Jean-Philippe André &
> > lt;j...@videolan.org>
> > > said:
> > >
> > > > Hello,
> > > >
> > > >
> > > > I would like to propose a new candidate for probie access:
> > Jee-Yong Um.
> > > >
> > > > Also known as conr2d, Jee-Yong has recently been sending a
> > series of
> > > > quality patches for EFL and Elementary, updating them quickly
> in
> > response
> > > > to review comments on Phab.
> > > >
> > > > He may be quite new to EFL and upstream in particular, he
> > tackles non
> > > > trivial issues in Edje, preparing the ground for a higher
> > quality API in
> > > > Elementary, including the theme API (size_class, color_class,
> > etc...).
> > > >
> > > >
> > > > He still has a couple of patches pending on Phab, and I believe
> > a probie
> > > > access would help him work more efficiently.
> > > >
> > > >
> > > > Any objections?
> > >
> > > +1
> > >
> > > >
> > > > Best regards,
> > > >
> > > > --
> > > > Jean-Philippe André
> > > >
> > >
> >
> --
> > > > ___
> > > > enlightenment-devel mailing list
> > > > enlightenment-devel@lists.sourceforge.net
> > > >
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > 
> >;
> > >
> > > --
> > > - Codito, ergo sum - "I code, therefore I am"
> > --
> > > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> > >
> > >
> > >
> > >
> >
> --
> > > ___
> > > 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
> >
> >
> --
> > ___
> > 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
>



-- 
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/elementary] master 03/03: widget: check next_item existence when focusing before calling widget fns

[Amitesh Singh]

Hello Mike

On Jan 7, 2016 3:40 AM, "Mike Blumenkrantz" 
wrote:
>
> discomfitor pushed a commit to branch master.
>
>
http://git.enlightenment.org/core/elementary.git/commit/?id=92481addac649391cd97d73f384dfe23603a4c87
>
> commit 92481addac649391cd97d73f384dfe23603a4c87
> Author: Mike Blumenkrantz 
> Date:   Wed Jan 6 17:05:44 2016 -0500
>
> widget: check next_item existence when focusing before calling widget
fns
>
> ERRlib/eo/eo.c:753 Unable to resolve op for api func
0x77cc17ce
> ---
>  src/lib/elm_widget.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/lib/elm_widget.c b/src/lib/elm_widget.c
> index f917d29..97ef045 100644
> --- a/src/lib/elm_widget.c
> +++ b/src/lib/elm_widget.c
> @@ -2432,7 +2432,8 @@ _elm_widget_focus_next_get(const Eo *obj,
Elm_Widget_Smart_Data *sd, Elm_Focus_D
> *next_item = sd->item_focus_right;
>   else if (dir == ELM_FOCUS_LEFT)
> *next_item = sd->item_focus_left;
> - o = elm_object_item_widget_get(*next_item);
> + if (*next_item)
> +   o = elm_object_item_widget_get(*next_item);
>
Thanks for the fix. This eo error was annoying for sometime and I noticed
it on day before yesterday when I was implementing a feature related to
focus.(this error comes when there is no next focusable object). Now I know
why eo was complaining about it. I knew it is related to some logic on
finding next object item and possibly next was null as the same error does
not come in case of prev focusable item (e.g. alt-tab..)
Unfortunately, I could not able to trace it as eo error was not giving much
information.  It would be super nice if you share how did you know the root
point. This would help others in future to hunt down similar problems in
future.

>   if (!o)
> {
>
> --
>
>
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel