[E-devel] Eina value optional

2016-01-12 Thread Jean-Philippe André 
Hi Felipe,

You added the optional type to eina value. I'm not sure what it's point is.
I understand an optional value can be empty (ie. void and not "nil" or 0 or
whatever).

But I don't understand why this couldn't be implemented inside all standard
values. Add an "empty" property to them.

Could you explain shortly why we need a special type? I'm sure you had a
good reason :)

Thanks in advance,

-- 
Jean-Philippe André
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Merging Efl and elementary

2016-01-12 Thread The Rasterman 
On Tue, 12 Jan 2016 22:00:59 +1030 Simon Lees  said:

> 
> 
> On 01/12/2016 09:41 PM, Stefan Schmidt wrote:
> > Hello.
> >
> > On 12/01/16 01:42, Cedric BAIL wrote:
> >> Hello,
> >>
> >> As we are moving forward with a stable API for binding, one of the
> >> main "weirdness" that is still exposed is that you need to actually
> >> require two differents library to use efl. Also the only reason why we
> >> haven't merged elementary so far as been because it still depend on
> >> webkit-efl and webkit-efl depend on elementary.
> >>
> >> I am going to address that during next efl release cycle, by moving
> >> the webkit dependency to be a module (like evas_generic_loaders and
> >> emotion_generic_loaders). Once that is done it will be technically
> >> possible to merge the both of them.
> >>
> >> This open a question, does anyone see any other reason to not merge
> >> elementary ?
> > Nothing really from my side which would block it. We need to make sure
> > having a --disable-elementary for people who do not want it as it is a
> > rather big piece of code. What I consider as a must for the merge is to
> > keep the git history elementary when merging it into the efl repo. Tom
> > should have the knowledge how he and Daniel Willmann did it before with
> > the other libs.
> Does the elementary build take that long? can they not build then rm 
> libelementary.so* and /usr/share/elementary/* like they need to do with 
> other libs they don't require.

they certainly can. thus i don't see the point of making it optional. it simply
affects build time and the very few who really don't want it can rm the build
results (headers, .so's, modules, data/theme files, binaries). they are all
clearly namespaced and trivial to remove.

rm -rf $PREFIX/bin/elementary* $PREFIX/share/elementary
$PREFIX/include/elementary* $PREFIX/lib/elementary $PREFIX/lib/libelementary*
$PREFIX/share/applications/elementary* $PREFIX/share/icons/elementary*
$PREFIX/lib/pkgconfig/elementary*

put that in your build script after the make install. that's all.

the extra build time is not that significant. and as i said - it's a niche
need. i don't think we need to or even should have a --disable for this as
disabling is solvable as above by the few who might want to.

> Having said that I don't care either way.
> 
> Cheers
> 
> Simon
> >
> >> If there is no other problem being seen to do this, there is a few
> >> things that will be impacted :
> >> - elementary developers branch can not be merged into an efl branch
> >> automatically. Developers will have to either finish their patch
> >> before we merge or have to take care themself of doing the move from
> >> an elementary branch to an efl branch.
> >>
> >> - for the same reason, phab patch on elementary that won't have landed
> >> before the merge will also be abandonned and their respective author
> >> will have to move their patch on top of efl new merged tree.
> > - Phab issues should just be batch moved from Elementary to EFL project
> > once the merge is done.
> >
> > - I will update accordingly for Jenkins jobs as well as the release
> > scripts and bits.
> >
> >> Due to the above effect, we should come with a clear timeline if and
> >> when we do that merge to allow everyone to handle that big of a change
> >> early enough to not loose time on patching the wrong piece of code.
> >> Also I think this is going to impact efl 1.18 release cycle, and maybe
> >> it should be adapted with maybe a technology preview in the middle of
> >> the release cycle just after the merge ?
> >>
> >> Stefan what is your take on such a big change ?
> > This will definitely not ft in our 3 months release scheme. We need some
> > extra days before to make sure people have a chance to merge there
> > existing branches, then some time to to prepare the repo, a hard freeze
> > so the final merge can happen without interruption and a week or two
> > stabilisation just to fix the fallout from the merge.
> >
> > My guts tell me that 4 extra weeks in our release schedule for the elm
> > merge are needed as minimum. I'm fine with adapting the 1.18 schedule
> > for it and we can come back to our well working 3 months schedule
> > afterwards. This would move it from beginning of May to beginning of June.
> >
> > As for the actual merge plan I gladly leave this in your hands. Here are
> > just some suggestions/ideas from my side.
> >
> > o After 1.17 is released we give people two weeks to get all the code
> > merged that is sitting in branches right just waiting for the freeze to
> > be over
> > o After this window we hard freeze the efl and elm repos master branches
> > for a week so you can work on the merge without interruption. People can
> > still work in their dev branches during this time.
> > o Once the merge is done we concentrate on making it work for all our
> > scenarios for two weeks without new features being merged.
> > o After that is done I'm happy to release a technical preview set of
> > tarballs to give p

Re: [E-devel] Merging Efl and elementary

2016-01-12 Thread The Rasterman 
On Tue, 12 Jan 2016 20:33:34 +1000 David Seikel  said:

> Hmm, no one else commented, so I will.
> 
> On Mon, 11 Jan 2016 16:42:45 -0800 Cedric BAIL 
> wrote:
> 
> > As we are moving forward with a stable API for binding, one of the
> > main "weirdness" that is still exposed is that you need to actually
> > require two differents library to use efl.
> 
> Actually no, EFL is quite useful without Elementary, so you don't NEED
> it to use EFL.  Of my two main EFL projects, one does and one does not
> use Elementary.  Even the one that does, I'm considering writing my own
> widget set, which I have mentioned before.  Since it's a reboot of an
> older project where I made it independent of widget set, likely I could
> do the same and make Elementary optional.

for the VAST MAJORITY of uses of efl - you need/want widgets and a higher level
abstraction. elementary is just that. that is the actual case. otherwise
everyone is off building their own widget set that is generally
half-implemented. implementing all the support from focus handling through to
accessibility, copy & paste, layout, the widgets and more is a pretty huge
undertaking and most alternate widget sets will be half-done at best without a
massive bit of work. so this offers a standardized implementation. Yes I can
and have made things where i don't need elementary. it's a minority of things.
we have to see the big picture, not all the tiny little exceptions.

all it costs you is a bit more efl build time and then you can rm the
elementary files that are installed if you don't want it. it doesn't cost extra
dependencies.

> Mind you, I AM trying to give Elementary a good try in this project.
> I'm not going to be dismissing it out of hand.  It will be quite a long
> time before I get around to writing my widget set.
> 
> > Also the only reason why we haven't merged elementary so far as been
> > because it still depend on webkit-efl and webkit-efl depend on
> > elementary.
> 
> Where would I find this webkit-efl?  A quick look through our git
> didn't turn it up for me.  I recall trying to compile some older web
> browser EFL thingy some time ago, not sure if it was that.  I do
> strongly remember that it was a giant rabbit hole that just kept
> getting deeper and deeper.  I eventually gave up trying to get it to
> build.  I also recall that very deep down that rabbit hole was a GPL3
> library, that infected everything else all the way up.

i seriously doubt that. webkit-efl is shipped on tizen and no gpl3 libraries in
sight. it would fundamentally break tizen's model if it depended on gpl3 for
the web view - tghus forcing apps to become gpl3 by derivation. perhaps there
was a build TOOL you installed - but webkit-efl does not depend on anything
gpl3 (at runtime).

> I'm planning an alternate approach to web browser support for my big
> Elementary project.  Actually, a couple of approaches.  The one thing I
> wont be doing is adding a humongous web browser to it.
> 
> > I am going to address that during next efl release cycle, by moving
> > the webkit dependency to be a module (like evas_generic_loaders and
> > emotion_generic_loaders). Once that is done it will be technically
> > possible to merge the both of them.
> 
> So long as it's optional.

rm the installed build files/dirs afterwards. :)

> > This open a question, does anyone see any other reason to not merge
> > elementary ?
> 
> So long as it's optional.
> 
> I've said before, the non Elementary project of mine really needs to be
> kept down to a minimum size.  My Elementary project is essentially a
> reboot of some one else's project, and that other project includes
> webkit, which takes up one third of the resulting package size.
> Considering that web pages is only a tiny part of what that project is
> all about, I find this to be unacceptable.  Wont be happening to my
> version.

rm rm rm :)

> Personally I find HTML standards to be very, very, very, very bloated,
> especially HTML 5.  I don't want to get any of that on me, especially
> since long ago I proved you don't need 99.9% of that bloat.  My ancient
> matrix-RAD project fit on a floppy disk, with binaries, source,
> examples, and full documentation.  It could do everything HTML 5
> could, before HTML 5 was invented.  My reboot's gonna be a little
> bigger.  lol
> 
> -- 
> A big old stinking pile of genius that no one wants
> coz there are too many silver coated monkeys in the world.


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


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_

Re: [E-devel] Work items for 1.17

2016-01-12 Thread Stefan Schmidt 
Hello.

On 07/01/16 17:11, Stefan Schmidt wrote:
> New APIs with missing test cases:
> -

These are coming from the beta1 ABI report. I checked if there is a 
corresponding text case for it manually and if not list it here.

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

Edje_Common.h
edje_mmap_size_class_iterator_new ( Eina_File* f )
edje_mmap_text_class_iterator_new ( Eina_File* f )
edje_size_class_active_iterator_new ( )
edje_size_class_del ( char const* size_class )
edje_text_class_active_iterator_new ( )

Efl_Model_Common.h
efl_model_error_notify ( Efl_Model_Base* model )
efl_model_list_slice ( Eina_List* list, unsigned int start, unsigned int 
count )
efl_model_load_set ( Efl_Model_Base* model, Efl_Model_Load* load, enum 
Efl_Model_Load_Status status )
efl_model_property_changed_notify ( Efl_Model_Base* model, char const* 
property )
efl_model_property_invalidated_notify ( Efl_Model_Base* model, char 
const* property )
efl_model_value_struct_description_free ( Eina_Value_Struct_Desc* desc )
efl_model_value_struct_description_new ( unsigned int member_count, 
Efl_Model_Value_Struct_Member_Setup_Cb setup_cb, void* data )

eina_inline_value.x
eina_value_optional_empty_new ( )
eina_value_optional_type_get ( Eina_Value* value )

eina_inline_vector.x
eina_vector2_add ( Eina_Vector2* out, Eina_Vector2 const* a, 
Eina_Vector2 const* b )
eina_vector2_array_set ( Eina_Vector2* dst, double const* v )
eina_vector2_copy ( Eina_Vector2* dst, Eina_Vector2 const* src )
eina_vector2_distance_get ( Eina_Vector2 const* a, Eina_Vector2 const* b )
eina_vector2_distance_square_get ( Eina_Vector2 const* a, Eina_Vector2 
const* b )
eina_vector2_dot_product ( Eina_Vector2 const* a, Eina_Vector2 const* b )
eina_vector2_homogeneous_direction_transform ( Eina_Vector2* out, 
Eina_Matrix3 const* m, Eina_Vector2 const* v )
eina_vector2_homogeneous_position_transform ( Eina_Vector2* out, 
Eina_Matrix3 const* m, Eina_Vector2 const* v )
eina_vector2_length_get ( Eina_Vector2 const* v )
eina_vector2_length_square_get ( Eina_Vector2 const* v )
eina_vector2_negate ( Eina_Vector2* out, Eina_Vector2 const* v )
eina_vector2_normalize ( Eina_Vector2* out, Eina_Vector2 const* v )
eina_vector2_scale ( Eina_Vector2* out, Eina_Vector2 const* v, double 
scale )
eina_vector2_set ( Eina_Vector2* dst, double x, double y )
eina_vector2_subtract ( Eina_Vector2* out, Eina_Vector2 const* a, 
Eina_Vector2 const* b )
eina_vector2_transform ( Eina_Vector2* out, Eina_Matrix2 const* m, 
Eina_Vector2 const* v )

eina_matrix.h
eina_normal3_matrix_get ( Eina_Matrix3* out, Eina_Matrix4 const* m )

eina_quaternion.h
eina_quaternion_subtract ( Eina_Quaternion* out, Eina_Quaternion const* 
a, Eina_Quaternion const* b )
eina_quaternion_transform ( Eina_Quaternion* out, Eina_Quaternion const* 
v, Eina_Matrix4 const* m )

eina_value.h
eina_value_optional_new ( Eina_Value_Type const* subtype, void const* 
value )

eldbus_freedesktop.h
eldbus_proxy_property_value_set ( Eldbus_Proxy* proxy, char const* name, 
char const* sig, Eina_Value const* value, void(*cb)(void*, 
Eldbus_Message const*, Eldbus_Pending*), void const* data )

eldbus_introspection.h
eldbus_introspection_argument_find ( Eina_List* arguments, char const* 
name )
eldbus_introspection_interface_find ( Eina_List* interfaces, char const* 
name )
eldbus_introspection_node_free ( Eldbus_Introspection_Node* node )
eldbus_introspection_parse ( char const* xml )
eldbus_introspection_property_find ( Eina_List* properties, char const* 
name )

If you are added any of these try to work out how to provide test cases 
for them.

regards
Stefan Schmidt

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
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.

2016-01-12 Thread David Seikel 
On Tue, 12 Jan 2016 21:57:12 +1000 David Seikel 
wrote:

> On Tue, 12 Jan 2016 21:42:39 +1000 David Seikel 
> wrote:
> 
> > I'm gonna start writing up some notes about this on phab now.  Or
> > rather, likely spend most of the night figuring out which of the
> > dozens of phab tools to use for this.  lol
> > 
> 
> https://phab.enlightenment.org/w/research_items/ seems like the right
> place.  I'll add it there.

Sorry Cedric, I wrote a novel.  Actually, most of it was copy pasted
from this email thread, though I did straighten it up and add more.

More research later, and I'll add more later as well.

-- 
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
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140___
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.

2016-01-12 Thread David Seikel 
On Tue, 12 Jan 2016 21:42:39 +1000 David Seikel 
wrote:

> I'm gonna start writing up some notes about this on phab now.  Or
> rather, likely spend most of the night figuring out which of the
> dozens of phab tools to use for this.  lol
> 

https://phab.enlightenment.org/w/research_items/ seems like the right
place.  I'll add it there.

-- 
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
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140___
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.

2016-01-12 Thread David Seikel 
I'm gonna start writing up some notes about this on phab now.  Or
rather, likely spend most of the night figuring out which of the dozens
of phab tools to use for this.  lol

-- 
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
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Merging Efl and elementary

2016-01-12 Thread Simon Lees 


On 01/12/2016 09:41 PM, Stefan Schmidt wrote:
> Hello.
>
> On 12/01/16 01:42, Cedric BAIL wrote:
>> Hello,
>>
>> As we are moving forward with a stable API for binding, one of the
>> main "weirdness" that is still exposed is that you need to actually
>> require two differents library to use efl. Also the only reason why we
>> haven't merged elementary so far as been because it still depend on
>> webkit-efl and webkit-efl depend on elementary.
>>
>> I am going to address that during next efl release cycle, by moving
>> the webkit dependency to be a module (like evas_generic_loaders and
>> emotion_generic_loaders). Once that is done it will be technically
>> possible to merge the both of them.
>>
>> This open a question, does anyone see any other reason to not merge 
>> elementary ?
> Nothing really from my side which would block it. We need to make sure
> having a --disable-elementary for people who do not want it as it is a
> rather big piece of code. What I consider as a must for the merge is to
> keep the git history elementary when merging it into the efl repo. Tom
> should have the knowledge how he and Daniel Willmann did it before with
> the other libs.
Does the elementary build take that long? can they not build then rm 
libelementary.so* and /usr/share/elementary/* like they need to do with 
other libs they don't require.

Having said that I don't care either way.

Cheers

Simon
>
>> If there is no other problem being seen to do this, there is a few
>> things that will be impacted :
>> - elementary developers branch can not be merged into an efl branch
>> automatically. Developers will have to either finish their patch
>> before we merge or have to take care themself of doing the move from
>> an elementary branch to an efl branch.
>>
>> - for the same reason, phab patch on elementary that won't have landed
>> before the merge will also be abandonned and their respective author
>> will have to move their patch on top of efl new merged tree.
> - Phab issues should just be batch moved from Elementary to EFL project
> once the merge is done.
>
> - I will update accordingly for Jenkins jobs as well as the release
> scripts and bits.
>
>> Due to the above effect, we should come with a clear timeline if and
>> when we do that merge to allow everyone to handle that big of a change
>> early enough to not loose time on patching the wrong piece of code.
>> Also I think this is going to impact efl 1.18 release cycle, and maybe
>> it should be adapted with maybe a technology preview in the middle of
>> the release cycle just after the merge ?
>>
>> Stefan what is your take on such a big change ?
> This will definitely not ft in our 3 months release scheme. We need some
> extra days before to make sure people have a chance to merge there
> existing branches, then some time to to prepare the repo, a hard freeze
> so the final merge can happen without interruption and a week or two
> stabilisation just to fix the fallout from the merge.
>
> My guts tell me that 4 extra weeks in our release schedule for the elm
> merge are needed as minimum. I'm fine with adapting the 1.18 schedule
> for it and we can come back to our well working 3 months schedule
> afterwards. This would move it from beginning of May to beginning of June.
>
> As for the actual merge plan I gladly leave this in your hands. Here are
> just some suggestions/ideas from my side.
>
> o After 1.17 is released we give people two weeks to get all the code
> merged that is sitting in branches right just waiting for the freeze to
> be over
> o After this window we hard freeze the efl and elm repos master branches
> for a week so you can work on the merge without interruption. People can
> still work in their dev branches during this time.
> o Once the merge is done we concentrate on making it work for all our
> scenarios for two weeks without new features being merged.
> o After that is done I'm happy to release a technical preview set of
> tarballs to give packagers and integrators an early idea what comes
> towards them.
> o After the technical preview is out I would go roughly into the 3 month
> schedule we had before. 2 months development, 1 months stabilisation. In
> a sense I would put the extra month for the merge just in front of our
> normal 1.18 schedule.
>
> regards
> Stefan Schmidt
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-

Re: [E-devel] Merging Efl and elementary

2016-01-12 Thread Stefan Schmidt 
Hello.

On 12/01/16 01:42, Cedric BAIL wrote:
> Hello,
>
> As we are moving forward with a stable API for binding, one of the
> main "weirdness" that is still exposed is that you need to actually
> require two differents library to use efl. Also the only reason why we
> haven't merged elementary so far as been because it still depend on
> webkit-efl and webkit-efl depend on elementary.
>
> I am going to address that during next efl release cycle, by moving
> the webkit dependency to be a module (like evas_generic_loaders and
> emotion_generic_loaders). Once that is done it will be technically
> possible to merge the both of them.
>
> This open a question, does anyone see any other reason to not merge 
> elementary ?

Nothing really from my side which would block it. We need to make sure 
having a --disable-elementary for people who do not want it as it is a 
rather big piece of code. What I consider as a must for the merge is to 
keep the git history elementary when merging it into the efl repo. Tom 
should have the knowledge how he and Daniel Willmann did it before with 
the other libs.

>
> If there is no other problem being seen to do this, there is a few
> things that will be impacted :
> - elementary developers branch can not be merged into an efl branch
> automatically. Developers will have to either finish their patch
> before we merge or have to take care themself of doing the move from
> an elementary branch to an efl branch.
>
> - for the same reason, phab patch on elementary that won't have landed
> before the merge will also be abandonned and their respective author
> will have to move their patch on top of efl new merged tree.

- Phab issues should just be batch moved from Elementary to EFL project 
once the merge is done.

- I will update accordingly for Jenkins jobs as well as the release 
scripts and bits.

>
> Due to the above effect, we should come with a clear timeline if and
> when we do that merge to allow everyone to handle that big of a change
> early enough to not loose time on patching the wrong piece of code.
> Also I think this is going to impact efl 1.18 release cycle, and maybe
> it should be adapted with maybe a technology preview in the middle of
> the release cycle just after the merge ?
>
> Stefan what is your take on such a big change ?

This will definitely not ft in our 3 months release scheme. We need some 
extra days before to make sure people have a chance to merge there 
existing branches, then some time to to prepare the repo, a hard freeze 
so the final merge can happen without interruption and a week or two 
stabilisation just to fix the fallout from the merge.

My guts tell me that 4 extra weeks in our release schedule for the elm 
merge are needed as minimum. I'm fine with adapting the 1.18 schedule 
for it and we can come back to our well working 3 months schedule 
afterwards. This would move it from beginning of May to beginning of June.

As for the actual merge plan I gladly leave this in your hands. Here are 
just some suggestions/ideas from my side.

o After 1.17 is released we give people two weeks to get all the code 
merged that is sitting in branches right just waiting for the freeze to 
be over
o After this window we hard freeze the efl and elm repos master branches 
for a week so you can work on the merge without interruption. People can 
still work in their dev branches during this time.
o Once the merge is done we concentrate on making it work for all our 
scenarios for two weeks without new features being merged.
o After that is done I'm happy to release a technical preview set of 
tarballs to give packagers and integrators an early idea what comes 
towards them.
o After the technical preview is out I would go roughly into the 3 month 
schedule we had before. 2 months development, 1 months stabilisation. In 
a sense I would put the extra month for the merge just in front of our 
normal 1.18 schedule.

regards
Stefan Schmidt

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Work items for 1.17

2016-01-12 Thread Tom Hacohen 
On 12/01/16 10:32, Stefan Schmidt wrote:
> Hello.
>
> Additionally to the other items here I have been running sparse and
> smatch on the code. Its a lot of noise so I'm not pasting the whole logs
> here but only some issues that might be worthwhile to look at. Keep in
> mind that these checkers could get things wrong and it turns out being a
> false positive.
>
> EFL:
> src/lib/emile/emile_main.c:149 emile_pbkdf2_sha1() warn: right shifting
> more than type allows
> src/lib/emile/emile_main.c:150 emile_pbkdf2_sha1() warn: right shifting
> more than type allows
> src/lib/emile/emile_main.c:151 emile_pbkdf2_sha1() warn: right shifting
> more than type allows
> src/lib/emile/emile_cipher_openssl.c:611
> _emile_cipher_client_handshake() warn: missing break? reassigning
> 'client->handshaking'
>
> src/lib/evas/canvas/evas_object_textblock.c:3625 _layout_line_finalize()
> warn: curly braces intended?

Yes. Made it more clear.

> src/lib/evas/canvas/evas_object_textblock.c:5515 _layout_par() warn:
> variable dereferenced before check 'c->par' (see line 5070)

We had a redundant check there. Removed now. Not a bug.

> src/lib/evas/canvas/evas_object_textblock.c:8198
> evas_textblock_cursor_word_start() warn: potentially one past the end of
> array 'breaks[i]'
> src/lib/evas/canvas/evas_object_textblock.c:8198
> evas_textblock_cursor_word_start() warn: potentially one past the end of
> array 'breaks[i]'
> src/lib/evas/canvas/evas_object_textblock.c:8274
> evas_textblock_cursor_word_end() warn: potentially one past the end of
> array 'breaks[i]'
> src/lib/evas/canvas/evas_object_textblock.c:8274
> evas_textblock_cursor_word_end() warn: potentially one past the end of
> array 'breaks[i]'

Looking at the first, it doesn't look wrong, and it complains on the 
same thing (the BREAK_AFTER macro) in all of them. It's hard to know 
what it wants with this little information, but it doesn't look wrong to 
me on the face of it.

> lib/evas/canvas/evas_object_textblock.c:9416:44: warning: Variable
> length array is used.

Warning: a semi-colon is used. VLAs are part of the language, stefan, 
please remove this warning.

--
Tom.

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
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

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

Updated to beta1.

Thanks to Stefan for reminding me. :)

--
Tom.


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Merging Efl and elementary

2016-01-12 Thread Stefan Schmidt 
Hello.

On 12/01/16 11:33, David Seikel wrote:
> Hmm, no one else commented, so I will.
>
> On Mon, 11 Jan 2016 16:42:45 -0800 Cedric BAIL 
> wrote:
>
>> Also the only reason why we haven't merged elementary so far as been
>> because it still depend on webkit-efl and webkit-efl depend on
>> elementary.
> Where would I find this webkit-efl?

https://download.enlightenment.org/rel/libs/webkit-efl/

This contains some release which have been made together with EFL. Where 
the latest code lives and how it is developed is still unclear to I have 
to say.

regards
Stefan Schmidt


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Merging Efl and elementary

2016-01-12 Thread David Seikel 
Hmm, no one else commented, so I will.

On Mon, 11 Jan 2016 16:42:45 -0800 Cedric BAIL 
wrote:

> As we are moving forward with a stable API for binding, one of the
> main "weirdness" that is still exposed is that you need to actually
> require two differents library to use efl.

Actually no, EFL is quite useful without Elementary, so you don't NEED
it to use EFL.  Of my two main EFL projects, one does and one does not
use Elementary.  Even the one that does, I'm considering writing my own
widget set, which I have mentioned before.  Since it's a reboot of an
older project where I made it independent of widget set, likely I could
do the same and make Elementary optional.

Mind you, I AM trying to give Elementary a good try in this project.
I'm not going to be dismissing it out of hand.  It will be quite a long
time before I get around to writing my widget set.

> Also the only reason why we haven't merged elementary so far as been
> because it still depend on webkit-efl and webkit-efl depend on
> elementary.

Where would I find this webkit-efl?  A quick look through our git
didn't turn it up for me.  I recall trying to compile some older web
browser EFL thingy some time ago, not sure if it was that.  I do
strongly remember that it was a giant rabbit hole that just kept
getting deeper and deeper.  I eventually gave up trying to get it to
build.  I also recall that very deep down that rabbit hole was a GPL3
library, that infected everything else all the way up.

I'm planning an alternate approach to web browser support for my big
Elementary project.  Actually, a couple of approaches.  The one thing I
wont be doing is adding a humongous web browser to it.

> I am going to address that during next efl release cycle, by moving
> the webkit dependency to be a module (like evas_generic_loaders and
> emotion_generic_loaders). Once that is done it will be technically
> possible to merge the both of them.

So long as it's optional.

> This open a question, does anyone see any other reason to not merge
> elementary ?

So long as it's optional.

I've said before, the non Elementary project of mine really needs to be
kept down to a minimum size.  My Elementary project is essentially a
reboot of some one else's project, and that other project includes
webkit, which takes up one third of the resulting package size.
Considering that web pages is only a tiny part of what that project is
all about, I find this to be unacceptable.  Wont be happening to my
version.

Personally I find HTML standards to be very, very, very, very bloated,
especially HTML 5.  I don't want to get any of that on me, especially
since long ago I proved you don't need 99.9% of that bloat.  My ancient
matrix-RAD project fit on a floppy disk, with binaries, source,
examples, and full documentation.  It could do everything HTML 5
could, before HTML 5 was invented.  My reboot's gonna be a little
bigger.  lol

-- 
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
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Work items for 1.17

2016-01-12 Thread Stefan Schmidt 
Hello.

Additionally to the other items here I have been running sparse and 
smatch on the code. Its a lot of noise so I'm not pasting the whole logs 
here but only some issues that might be worthwhile to look at. Keep in 
mind that these checkers could get things wrong and it turns out being a 
false positive.

EFL:
src/lib/emile/emile_main.c:149 emile_pbkdf2_sha1() warn: right shifting 
more than type allows
src/lib/emile/emile_main.c:150 emile_pbkdf2_sha1() warn: right shifting 
more than type allows
src/lib/emile/emile_main.c:151 emile_pbkdf2_sha1() warn: right shifting 
more than type allows
src/lib/emile/emile_cipher_openssl.c:611 
_emile_cipher_client_handshake() warn: missing break? reassigning 
'client->handshaking'

src/lib/evas/canvas/evas_object_textblock.c:3625 _layout_line_finalize() 
warn: curly braces intended?
src/lib/evas/canvas/evas_object_textblock.c:5515 _layout_par() warn: 
variable dereferenced before check 'c->par' (see line 5070)
src/lib/evas/canvas/evas_object_textblock.c:8198 
evas_textblock_cursor_word_start() warn: potentially one past the end of 
array 'breaks[i]'
src/lib/evas/canvas/evas_object_textblock.c:8198 
evas_textblock_cursor_word_start() warn: potentially one past the end of 
array 'breaks[i]'
src/lib/evas/canvas/evas_object_textblock.c:8274 
evas_textblock_cursor_word_end() warn: potentially one past the end of 
array 'breaks[i]'
src/lib/evas/canvas/evas_object_textblock.c:8274 
evas_textblock_cursor_word_end() warn: potentially one past the end of 
array 'breaks[i]'
lib/evas/canvas/evas_object_textblock.c:9416:44: warning: Variable 
length array is used.

src/lib/evas/canvas/evas_render.c:1993 evas_render_mask_subrender() 
warn: maybe use && instead of &

lib/evas/filters/evas_filter.c:1284:14: warning: variable 'use_clip' set 
but not used [-Wunused-but-set-variable]
 Eina_Bool use_clip = EINA_FALSE;

src/modules/evas/image_loaders/xpm/evas_image_load_xpm.c:442 
evas_image_load_file_xpm() error: buffer overflow 'line' 256 <= 65535
src/modules/evas/image_loaders/xpm/evas_image_load_xpm.c:470 
evas_image_load_file_xpm() error: buffer overflow 'line' 256 <= 65535
src/modules/evas/image_loaders/xpm/evas_image_load_xpm.c:489 
evas_image_load_file_xpm() error: buffer overflow 'line' 256 <= 65535
src/modules/evas/image_loaders/xpm/evas_image_load_xpm.c:520 
evas_image_load_file_xpm() error: buffer overflow 'line' 256 <= 65535
src/modules/evas/image_loaders/xpm/evas_image_load_xpm.c:542 
evas_image_load_file_xpm() error: buffer overflow 'line' 256 <= 65535
src/modules/evas/image_loaders/xpm/evas_image_load_xpm.c:580 
evas_image_load_file_xpm() error: buffer overflow 'line' 256 <= 65535

src/lib/eet/eet_data.c:1755 _eet_descriptor_hash_new() warn: double 
check that we're allocating correct size: 16 vs 1024
src/lib/eet/eet_data.c:4515 eet_data_get_variant() warn: double check 
that we're allocating correct size: 12 vs 11

src/lib/eet/eet_lib.c:806 eet_internal_read2() warn: double check that 
we're allocating correct size: 8 vs 2048
src/lib/eet/eet_lib.c:2251 eet_alias() warn: double check that we're 
allocating correct size: 8 vs 2048
src/lib/eet/eet_lib.c:2372 eet_write_cipher() warn: double check that 
we're allocating correct size: 8 vs 2048


Elementary:
src/lib/elm_datetime.c:300 _parse_format() error: buffer overflow 
'mapping' 6 <= 6

If you are spotting some of your code here please have a look at the report.

regards
Stefan Schmidt

On 11/01/16 13:54, Stefan Schmidt wrote:
> Hello.
>
> Update after beta1 is out.
>
> On 07/01/16 17:11, Stefan Schmidt wrote:
>> Hello.
>>
>> This comes up from my personal run through phab. Might be misguided,
>> wrong or I might even had forgotten something.
>> Speak up if this is the case.
>>
>> Please have a look at the following and see if you can help to fix them.
>>
>> Phab show stopper:
>> --
>> https://phab.enlightenment.org/T3008 The alignment of popup is wrong
> I pinged the author privately as well now to get something worked out.
> If that fails I will be going to revert the offending commit.
>
>> Phab high:
>> --
>> https://phab.enlightenment.org/T2042 evas_object_geometry_get called on
>> elm_ctxpopup object always returns width and height equals to 0
> This one is closed now.
>
>> https://phab.enlightenment.org/T2940
>> tests/eina_cxx/eina_cxx_test_ptrlist.cc does not compile on Windows
>>
>> https://phab.enlightenment.org/T2938 The example evas-vg-simple.c seg
>> fault on Windows
>>
>> https://phab.enlightenment.org/T2835 elementary application segfaults
>> when window type is set to ELM_WIN_SOCKET_IMAGE
>>
>> https://phab.enlightenment.org/T2789 evas image delete crash
>>
>> https://phab.enlightenment.org/T2708 Genlist tree+homogeneous broken
> The 5 above are still in need of a solution. Please help out.
>
>> Coverity high impact:
>> -
> EFL high impact:
> CID 1347412 Resource leak (ector_gl_surface)
>

Re: [E-devel] Enlightenment Developer Days 2016

2016-01-12 Thread Stefan Schmidt 
Hello.

On 11/01/16 21:24, Stefan Schmidt wrote:
> Hello.
>
> After the voting for the best date concluded the May 14th to 16th we can
> now move forward with the planning.
>
> Due to the tight timing from last year we want to plan this all a bit in
> advance to allow for VISA process, travel and schedule planning.
>
> You can already start participating. Make sure you vote of you are
> coming or not.
> https://phab.enlightenment.org/V16
>
> You can also start to propose a talk or a hands on session. We are
> having 2-3 days this year (I still wait for the final confirmation of
> the meeting room for the Monday) which means we have plenty of time for
> longer talks or hands on sessions if people are interested. We will also
> have time for hackathon session which might run under a theme if we can
> get enough people interested. All in all we are very flexible with the
> program depending on what feedback we get.
>
> If you want to propose a talk, a hands on session, a hackathon theme or
> something else plese send a mail to efl-dev-day-...@lists.s-osg.org .
> Title and short abstracts would be good as well as the time you expect
> it will take. The same address can be used to request a VISA invitation
> letter which might be needed for some folks. Please give us plenty of
> time doing them by submitting your request early. The deadline for the
> Call for Participation is March 15th.
>
> We would be also interested in feedback about some social event part.
>   From the locals of what they think would be nice and from the
> foreigners about what they expect. :)
>
> Once the wiki is back in working state we will prepare a wiki page
> holding all known details until know.

Wiki page is up now. It should be visible even to people not logged into 
phab. They will not see the names and avatars of the voters but still 
the actual vote.

https://phab.enlightenment.org/w/events/enlightenment_developer_days_2016/

regards
Stefan Schmidt

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/elementary] master 02/03: popup: add popup default align config for other profiles.

2016-01-12 Thread Andrew Williams 
Hi,

Would this maybe be resolved by bumping the elementary config version and
moving the 0.5 default setting to a new minor revision? src/lib/elm_config.c


Just a thought,
Andrew

On Sun, 10 Jan 2016 at 15:44 Andrew Williams  wrote:

> \o/ I though this one was just me!
>
> Cheers,
> Andy
> On Tue, 5 Jan 2016 at 15:46, Stefan Schmidt 
> wrote:
>
>> Hello.
>>
>> On 05/01/16 16:32, Davide Andreoli wrote:
>> > 2016-01-05 11:26 GMT+01:00 Stefan Schmidt :
>> >
>> >> Hello.
>> >>
>> >> On 04/01/16 14:11, Davide Andreoli wrote:
>> >>> 2015-12-20 18:55 GMT+01:00 Davide Andreoli :
>> >>>
>>  2015-12-08 1:39 GMT+01:00 taehyub :
>> 
>> > cedric pushed a commit to branch master.
>> >
>> >
>> >
>> >>
>> http://git.enlightenment.org/core/elementary.git/commit/?id=61648ba5a38bc8ab1e7a4721f17683abc701ebd4
>> > commit 61648ba5a38bc8ab1e7a4721f17683abc701ebd4
>> > Author: taehyub 
>> > Date:   Mon Dec 7 15:53:47 2015 -0800
>> >
>> >   popup: add popup default align config for other profiles.
>> >
>> >   Summary:
>> >   The alignment of popup can be different in each profiles.
>> >   So I added the align configuration of popup.
>> >   @feature
>> >
>>  After this commit (I think) all the popup on my system appear
>> top-left
>>  aligned.
>> 
>>  Reading the commit seems quite clear that you need a fresh elm config
>>  to have the popups correcly aligned...   :/
>> 
>> >>> So? no one replayed to this  :( cedric?
>> >>>
>> >>> I think we still have broken popup align everywhere (unless you wipe
>> your
>> >>> elm config)
>> >> Do we have a phab ticket for this one? If not it would be good to have
>> >> it so I can put it on my 1.17 task list which keeps track of things we
>> >> need to take care of before 1.17.
>> >>
>> >
>> >   T3008 created right now
>> >
>>
>> And you already put it into show stoppers, thanks. I will work on the
>> 1.17 task list tomorrow.
>>
>> regards
>> Stefan Schmidt
>>
>>
>> --
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] EFL and friends 1.17.0 beta 1

2016-01-12 Thread Stefan Schmidt 
A bunch of fresh new tarballs with our latest work waiting for your 
testing before we can go into the final stages of releases.

= EFL, Elementary and friends 1.17 beta1 tarballs =

One week after our alpa1 tarballs we just released our first beta 
tarballs. Please grab and test.

== Download ==
Its getting a long post so the most important stuff upfront. Downloads. :-)

http://download.enlightenment.org/rel/libs/efl/efl-1.17.0-beta1.tar.gz
16af2bd0633a2c6b1b656ed07921311a33a7a6964b7fe89e5ea4b05d3944e0a7

http://download.enlightenment.org/rel/libs/elementary/elementary-1.17.0-beta1.tar.gz
38fde76ea2c531f2109e7d764626c518be6cd58192127fb2e83e6f9430e764bf

http://download.enlightenment.org/rel/libs/emotion_generic_players/emotion_generic_players-1.17.0-beta1.tar.gz
c0d1463865a50a5d1965152fe384b53a48793cea297701e222d3d14431929050

http://download.enlightenment.org/rel/libs/evas_generic_loaders/evas_generic_loaders-1.17.0-beta1.tar.gz
1cd92de9eb616064c4142d8e5167e9cc8badd9804f558bdba24dde21284e3202



= What's New =
New since alpa1:

== EFL ==

Fixes:

* eina_js: Fix documentation generation (T3005)
* ecore-wl2: Fix support for nested compositors
* efreet: fix undeclared function
* ecore_con: fix compiling on OS X
* evas_gl_cocoa: update function parameters
* ecore_wayland: set touch_focus window when gets pointer_enter
* eina mp: only include malloc.h on linux
* js: fix binding after namespace change of connector
* Edje UI mirroring: Fix UI mirroring for GROUP parts. (T3021)
* Edje entry: Fix memory leak.

== Elementary ==

Features:

* ctxpopup: add geometry,update smart callback. (T2042)

Fixes:

* sys_notify: fix shutdown of elm_sys_notify
* segment_control: check item disable (T2883)
* elementary_test: remove wrong usage of EINA_UNUSED.
* layout: do not unset max size hint during sizing eval
* hide indicator after mouse wheel activation. (T2348)
* combobox: fix recalc and hover's best_location error
* js: fix examples functions
* elm entry: check for null return from eina_rectangle_new

== Evas Generic Loaders==

== Emotion Generic Players ==




--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel