Re: [E-devel] Fwd: Getting rid of eo_do_*ret
On 29/06/15 14:32, Cedric BAIL wrote: Hello, I think that eo_do_ret and eo_do_super_ret are quite hugly to use and unecessary. I think they should be gone. Their behavior can still be nice to have especially inside efl tree. The reason they exist is that we want to support other compiler than GCC and Clang for application that use EFL. EFL itself can not be compiled by anything else than GCC and Clang. Maybe we should provide #if piece of code that will enable the old non portable behavior of eo_do and eo_do_super for people who are sure that there code should not be running on something else than GCC and Clang. So if someone want the current behavior of eo_do_ret and eo_do_super_ret, but in a nice way, he will just do a #define EFL_GNU (or whatever we decide) before including Eo.h. As we are heading to stabilize Eo API in EFL 1.15, I really would prefer to get rid of this _ret variant. I don't see why this ret variant is a problem. We could keep it there, there's no problem with that. It's useful for people want to write portable code. For the different eo_do behaviour, we could have a define that changes eo_do to the non portable version if we think it's really needed. I don't really like the idea, but I don't object. Just offering a better way of doing it. :) -- Tom. -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: Getting rid of eo_do_*ret
On Mon, Jun 29, 2015 at 2:32 PM, Cedric BAIL cedric.b...@free.fr wrote: Hello, I think that eo_do_ret and eo_do_super_ret are quite hugly to use and unecessary. I think they should be gone. Their behavior can still be nice to have especially inside efl tree. The reason they exist is that we want to support other compiler than GCC and Clang for application that use EFL. EFL itself can not be compiled by anything else than GCC and Clang. Maybe we should provide #if piece of code that will enable the old non portable behavior of eo_do and eo_do_super for people who are sure that there code should not be running on something else than GCC and Clang. So if someone want the current behavior of eo_do_ret and eo_do_super_ret, but in a nice way, he will just do a #define EFL_GNU (or whatever we decide) before including Eo.h. That sounds terrible... As we are heading to stabilize Eo API in EFL 1.15, I really would prefer to get rid of this _ret variant. -- Cedric BAIL -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Fwd: Getting rid of eo_do_*ret
Hello, I think that eo_do_ret and eo_do_super_ret are quite hugly to use and unecessary. I think they should be gone. Their behavior can still be nice to have especially inside efl tree. The reason they exist is that we want to support other compiler than GCC and Clang for application that use EFL. EFL itself can not be compiled by anything else than GCC and Clang. Maybe we should provide #if piece of code that will enable the old non portable behavior of eo_do and eo_do_super for people who are sure that there code should not be running on something else than GCC and Clang. So if someone want the current behavior of eo_do_ret and eo_do_super_ret, but in a nice way, he will just do a #define EFL_GNU (or whatever we decide) before including Eo.h. As we are heading to stabilize Eo API in EFL 1.15, I really would prefer to get rid of this _ret variant. -- Cedric BAIL -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Intent to freeze
On 27/06/15 17:14, Michael Blumenkrantz wrote: On Sat, 27 Jun 2015 15:45:38 +0100 Tom Hacohen t...@stosb.com wrote: Hey, Cool, let's get this baby out of the door! A lot of exciting stuff going on. Just two comments: 1. It's a bit of a short notice, would be great to have a longer one. I'd recommend looking at how it's done in the EFL where everything is known months in advance. I can appreciate that it may be short notice, but consider that Enlightenment has been in full-on development mode for 9+ months. If anyone truly had any critical features to merge (which I am not already aware of), they've had ample time to come forward during this period. Furthermore, while I may be reluctant to merge new things after the freeze, it is by no means impossible to do so. If someone comes up with something novel and interesting which has little chance of creating large bugs for me to fix, it's probable that I'll accept it. The length of the development cycle makes the short notice even worse. People expect a long cycle from e, so it's easier to procrastinate (in comparison to the efl), and such a short notice makes it hard for people to figure out what they still need/want to do. Anyhow, my problem with it is less about it being short, and more about it being unnecessarily short. There's no real reason why not give a proper notice. I assume you didn't just wake up one day and told yourself oh, actually, we didn't have a release in a while, let's do one.. I assume there was planning involved and that you knew what was missing for weeks/months before this announcement. This can be done way in advance. Anyhow, for the next release, please let's have a more concrete plan with a sufficient advance warning. 2. What is the timeline for the release? Given that Wayland is still being actively developed and not frozen, and that e20 is not going to be released before efl 1.15, e will be in feature freeze for a long time. Feels a bit excessive. In my estimation, = 1 month of feature freeze (1.15 is scheduled for 3 August 2015) prior to release after a 9 month development cycle is actually a very short freeze. While I would like to provide a concrete release-by schedule, Enlightenment development is a bit different from EFL, and I am strongly opposed to setting such a deadline given the extremely limited manpower actively working on Enlightenment. Oh wow, it's July already. OK, then the efl release is not a blocker in that regard. I also don't want/expect a strict time based release cycle for e. However we should strive for a shorter, more defined release cycle. In my point of view, communication and transparency are key for good open source collaborations, and I think we need to improve on that front. The limited manpower is a chicken and egg kind of thing. There's no reason to have the collaborative overhead in a project that has only a few contributors, but if you don't have the collaborative overhead, new contributors won't come. We need to consider that. Ideally, E20 will release prior to EFL 1.16, but this is nothing more than my responding to questions of When will E17 be released? with Soon. It was a bad answer then, and it's a bad answer now. A better answer would be: once we get Wayland to XYZ and go through a week of not finding any major bugs, or whatever other criteria we find fit. Again, transparency and communication. Please let me know if you disagree, I'm happy to discuss it further. -- Tom. -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Intent to freeze
Hello. On 29/06/15 11:43, Carsten Haitzler wrote: On Mon, 29 Jun 2015 09:06:14 +0200 Stefan Schmidt ste...@osg.samsung.com said: Hello. On 28/06/15 06:40, Carsten Haitzler wrote: On Sat, 27 Jun 2015 09:05:02 -0400 Christopher Michael cpmich...@osg.samsung.com said: On 06/27/2015 01:14 AM, Carsten Haitzler wrote: On Fri, 26 Jun 2015 16:11:45 -0400 Mike Blumenkrantz michael.blumenkra...@gmail.com said: With a few minor exceptions in Wayland, all target features for the E20 release have been met. As such, I am planning to commence an everything-but-wayland feature freeze on Friday, 3 July 2015. If anyone has things that they want to push in or implement before the freeze begins, I'm open to moving back the date as necessary--within reason. I will not, however, be very receptive to adding new features once the release cycle freeze has begun. actually - devilhorns. you need to pipe in here - what is the wayland state, and what would there be left to drop in after july 3 and what timetable? As far as what is left: DnD needs a bit of testing/tweaking yet as there are some little buggers floating in there (I'll be hacking on that come Monday). We have pending patches to support wl_text_input and wl_input_method (https://phab.enlightenment.org/D2275) however we cannot securely push those until we have a working VKbd implementation to go with them. I pinged shiin to see if he could also hack up a vkbd to go with. While not a Top priority, support for wl_scaler and wl_viewport would be remaining things to drop in after July 3. We have pending patches for that also (https://phab.enlightenment.org/D2485) however those need some refactoring. i am saying this from the perspective that we get a fair number of does e run wayland yet kind of questions and the answer is always nebulous. i think we want a clear state of play for an e20 release. While I have not tested it yet, Mike has updated/refactored my initial XWayland branch and pushed that upstream already which means we should have working XWayland support now. I've not tested it yet myself however he did manage to get Firefox running with it (which is good news) :) E/Elm apps are running good in E-Wl. Gtk apps also (tho Some gtk apps have popup menu placement issues according to Phab reports). I don't suspect that those are Major issues and likely will take little time to fix. QT apps on the other hand are a whole different can of worms. Apparenly, QT5 has not been updated yet to support xdg_shell version 5 which means, while the apps do run, they have quite a few issues. I spoke with RzR about it and he plans to update QT5 to support xdg_shell version 5 which should address issues there. There are a few pending buggers listed on Phab which I/we will be addressing in the coming weeks tho I don't think any of them are Major problems (in terms of functionality). It is likely that I may be forgetting something in this list, so if you can think of something I may have missed, please ask. the question reading between the lines from users is: can i now use E20 to switch to wayland? :) i've talked with you about this - i know that i personally can't. my 2 main desktop systems have new nvidia rigs and literally have zero nouveau support. i know i'm not the only one and for many nouveau is still iffy. i am sure we could get more people working on wayland if we could run e in a window in x11 - ie wl-x11. like weston does. with a but of imagination it'd be possible to get full acceleration for egl working too. from a pr point of view, for many people they'd like to see how e wayland is going without having to drop out of x11 to do it. this'd help answer a lot of questions people have. :) it'd also mean a LOT more helping getting wayland moving along. btw - how goes session recovering with uuid's etc. ... stefan? The uuid store is in for some time. I have branch with a wayland protocol extension to pass the uuid arround which I can push in later today or tomorrow. What is still missing the re-connect handling, keeping apps alive and making sure they come back correctly when the compositor comes back. thats a necessary part of the uuid thing. it needs all of these done to be done: 1. store of uuids that survives e segs/restarts correctly (tho not logout/in) Its a mmaped object named /e_uuid_store and E checks for it during start/restart. What information will be applied is policy and part of #4. 2. protocol to assign uuids and pass them around back to comp That is what I will put in today or tomorrow. 3. reconnect code that correctly uses assigned uuids I played around with that but did not had it working so far. That is the bigger part of what is missing. 4. code to restore state of windows with these uuids based on store in #1 Once #3 works reliable this should not be to complicated. :) sounds like you're missing some bits. :) we need all 4 bits. :) Correct analysis.
Re: [E-devel] Intent to freeze
On Mon, 29 Jun 2015 09:06:14 +0200 Stefan Schmidt ste...@osg.samsung.com said: Hello. On 28/06/15 06:40, Carsten Haitzler wrote: On Sat, 27 Jun 2015 09:05:02 -0400 Christopher Michael cpmich...@osg.samsung.com said: On 06/27/2015 01:14 AM, Carsten Haitzler wrote: On Fri, 26 Jun 2015 16:11:45 -0400 Mike Blumenkrantz michael.blumenkra...@gmail.com said: With a few minor exceptions in Wayland, all target features for the E20 release have been met. As such, I am planning to commence an everything-but-wayland feature freeze on Friday, 3 July 2015. If anyone has things that they want to push in or implement before the freeze begins, I'm open to moving back the date as necessary--within reason. I will not, however, be very receptive to adding new features once the release cycle freeze has begun. actually - devilhorns. you need to pipe in here - what is the wayland state, and what would there be left to drop in after july 3 and what timetable? As far as what is left: DnD needs a bit of testing/tweaking yet as there are some little buggers floating in there (I'll be hacking on that come Monday). We have pending patches to support wl_text_input and wl_input_method (https://phab.enlightenment.org/D2275) however we cannot securely push those until we have a working VKbd implementation to go with them. I pinged shiin to see if he could also hack up a vkbd to go with. While not a Top priority, support for wl_scaler and wl_viewport would be remaining things to drop in after July 3. We have pending patches for that also (https://phab.enlightenment.org/D2485) however those need some refactoring. i am saying this from the perspective that we get a fair number of does e run wayland yet kind of questions and the answer is always nebulous. i think we want a clear state of play for an e20 release. While I have not tested it yet, Mike has updated/refactored my initial XWayland branch and pushed that upstream already which means we should have working XWayland support now. I've not tested it yet myself however he did manage to get Firefox running with it (which is good news) :) E/Elm apps are running good in E-Wl. Gtk apps also (tho Some gtk apps have popup menu placement issues according to Phab reports). I don't suspect that those are Major issues and likely will take little time to fix. QT apps on the other hand are a whole different can of worms. Apparenly, QT5 has not been updated yet to support xdg_shell version 5 which means, while the apps do run, they have quite a few issues. I spoke with RzR about it and he plans to update QT5 to support xdg_shell version 5 which should address issues there. There are a few pending buggers listed on Phab which I/we will be addressing in the coming weeks tho I don't think any of them are Major problems (in terms of functionality). It is likely that I may be forgetting something in this list, so if you can think of something I may have missed, please ask. the question reading between the lines from users is: can i now use E20 to switch to wayland? :) i've talked with you about this - i know that i personally can't. my 2 main desktop systems have new nvidia rigs and literally have zero nouveau support. i know i'm not the only one and for many nouveau is still iffy. i am sure we could get more people working on wayland if we could run e in a window in x11 - ie wl-x11. like weston does. with a but of imagination it'd be possible to get full acceleration for egl working too. from a pr point of view, for many people they'd like to see how e wayland is going without having to drop out of x11 to do it. this'd help answer a lot of questions people have. :) it'd also mean a LOT more helping getting wayland moving along. btw - how goes session recovering with uuid's etc. ... stefan? The uuid store is in for some time. I have branch with a wayland protocol extension to pass the uuid arround which I can push in later today or tomorrow. What is still missing the re-connect handling, keeping apps alive and making sure they come back correctly when the compositor comes back. thats a necessary part of the uuid thing. it needs all of these done to be done: 1. store of uuids that survives e segs/restarts correctly (tho not logout/in) 2. protocol to assign uuids and pass them around back to comp 3. reconnect code that correctly uses assigned uuids 4. code to restore state of windows with these uuids based on store in #1 :) sounds like you're missing some bits. :) we need all 4 bits. :) As I will be mostly offline for the next three weeks starting from tomorrow afternoon this has to wait until beginning of August. Given this is wayland only right now it should be within the scope for wayland fixes in the freeze. EFL 1.15 needs to be out before e20 in any case. sure. but i see that is why it looks like its not there. missing
Re: [E-devel] Fwd: Getting rid of eo_do_*ret
On 29/06/15 15:53, Cedric BAIL wrote: On Mon, Jun 29, 2015 at 4:18 PM, Tom Hacohen t...@osg.samsung.com wrote: On 29/06/15 14:32, Cedric BAIL wrote: I think that eo_do_ret and eo_do_super_ret are quite hugly to use and unecessary. I think they should be gone. Their behavior can still be nice to have especially inside efl tree. The reason they exist is that we want to support other compiler than GCC and Clang for application that use EFL. EFL itself can not be compiled by anything else than GCC and Clang. Maybe we should provide #if piece of code that will enable the old non portable behavior of eo_do and eo_do_super for people who are sure that there code should not be running on something else than GCC and Clang. So if someone want the current behavior of eo_do_ret and eo_do_super_ret, but in a nice way, he will just do a #define EFL_GNU (or whatever we decide) before including Eo.h. As we are heading to stabilize Eo API in EFL 1.15, I really would prefer to get rid of this _ret variant. I don't see why this ret variant is a problem. We could keep it there, It is a very confusing one. You have to pass the variable you want it to return stuff in. Once you are at the point of needing a variable, well, ... why do you still need to use eo_do_ret ? Basically useless. It's not useless, it's good for things like: if (eo_do_ret(...)) but mostly for things like: if (something) else if (eo_do_ret(...)) or if (something eo_do_ret(...)) there's no problem with that. It's useful for people want to write portable code. For the different eo_do behaviour, we could have a define that changes eo_do to the non portable version if we think it's really needed. I don't really like the idea, but I don't object. Just offering a better way of doing it. :) I fail to see the difference with my proposal, but if you are fine with it, then go. I'm not fine and not not fine. I wanna see what people say. At the moment, Daniel objects, you are in favour and I'm neutral. -- Tom. -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: Getting rid of eo_do_*ret
On Mon, Jun 29, 2015 at 4:18 PM, Tom Hacohen t...@osg.samsung.com wrote: On 29/06/15 14:32, Cedric BAIL wrote: I think that eo_do_ret and eo_do_super_ret are quite hugly to use and unecessary. I think they should be gone. Their behavior can still be nice to have especially inside efl tree. The reason they exist is that we want to support other compiler than GCC and Clang for application that use EFL. EFL itself can not be compiled by anything else than GCC and Clang. Maybe we should provide #if piece of code that will enable the old non portable behavior of eo_do and eo_do_super for people who are sure that there code should not be running on something else than GCC and Clang. So if someone want the current behavior of eo_do_ret and eo_do_super_ret, but in a nice way, he will just do a #define EFL_GNU (or whatever we decide) before including Eo.h. As we are heading to stabilize Eo API in EFL 1.15, I really would prefer to get rid of this _ret variant. I don't see why this ret variant is a problem. We could keep it there, It is a very confusing one. You have to pass the variable you want it to return stuff in. Once you are at the point of needing a variable, well, ... why do you still need to use eo_do_ret ? Basically useless. there's no problem with that. It's useful for people want to write portable code. For the different eo_do behaviour, we could have a define that changes eo_do to the non portable version if we think it's really needed. I don't really like the idea, but I don't object. Just offering a better way of doing it. :) I fail to see the difference with my proposal, but if you are fine with it, then go. -- Cedric BAIL -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [admin/devs] master 01/01: Let's welcome SangHyeon Lee !
Congratulations! I hope you will do a distinguishable contributions to EFL community with the permission! With great power comes great responsibility! Thanks, Daniel Juyung Seo (SeoZ) On Mon, Jun 29, 2015 at 10:15 PM, Cedric BAIL ced...@osg.samsung.com wrote: cedric pushed a commit to branch master. http://git.enlightenment.org/admin/devs.git/commit/?id=f8b183af688025feb4a3c5cfb43c00ccf4ceab88 commit f8b183af688025feb4a3c5cfb43c00ccf4ceab88 Author: Cedric BAIL ced...@osg.samsung.com Date: Mon Jun 29 15:15:00 2015 +0200 Let's welcome SangHyeon Lee ! --- developers/sanghyeonlee/id_rsa.pub | 1 + developers/sanghyeonlee/info.txt | 10 ++ 2 files changed, 11 insertions(+) diff --git a/developers/sanghyeonlee/id_rsa.pub b/developers/sanghyeonlee/id_rsa.pub new file mode 100644 index 000..694d3bc --- /dev/null +++ b/developers/sanghyeonlee/id_rsa.pub @@ -0,0 +1 @@ +ssh-rsa B3NzaC1yc2EDAQABAAABAQClq5KwmQn5pFILPDyMxoek6lxpR2uAzD47kqZ1sfRKlG980vmBEJosg5Wwt6wg8rKvoAt0e3tcU6WngOvNLstwFkBVvGl9VXKwKvUOEEN5nwcjUBKw337B3xjQm9Iwe5XFVJW6tgE2woPYSFJ3XFqxmMxSQBPNYC2WGrniFAfCUwPaOmtz0jby9DfuzOXtH6smo9+WU0qaDquNl/DCnkKPBhCT6J/8uEGiDlxnbW+z3dBOpkoUfKPWz8UgWf11QYMk/qbLcnnADBp+NBJPQormARmf+8fM+Z9Td90VXVrAsVUV8ej1VQNVcpx6svIpOpFxlmZES6fDC33NlOQ/N8fL sh10233lee@sh10233lee-linux diff --git a/developers/sanghyeonlee/info.txt b/developers/sanghyeonlee/info.txt new file mode 100644 index 000..ff93ca9 --- /dev/null +++ b/developers/sanghyeonlee/info.txt @@ -0,0 +1,10 @@ +Login:SanghyeonLee +IRC Nick: Jade_L +Name: SangHyeon Lee +Location: Suwon, Korea +E-Mail: dltkdgus1...@gmail.com, sh10233@samsung.com +Managing: elementary(genlist,gengrid) +Contributing: efl, elementary +Group:Core, Libraries, Applications +Platform: Ubuntu(Linux), Tizen(Linux), Windows +GeoData: 37.257920, 127.059776 -- -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: Getting rid of eo_do_*ret
On Mon, Jun 29, 2015 at 5:50 PM, Tom Hacohen t...@osg.samsung.com wrote:
On 29/06/15 15:53, Cedric BAIL wrote:
On Mon, Jun 29, 2015 at 4:18 PM, Tom Hacohen t...@osg.samsung.com wrote:
On 29/06/15 14:32, Cedric BAIL wrote:
I think that eo_do_ret and eo_do_super_ret are quite hugly to use and
unecessary. I think they should be gone. Their behavior can still be
nice to have especially inside efl tree. The reason they exist is that
we want to support other compiler than GCC and Clang for application
that use EFL. EFL itself can not be compiled by anything else than GCC
and Clang.
Maybe we should provide #if piece of code that will enable the old
non portable behavior of eo_do and eo_do_super for people who are sure
that there code should not be running on something else than GCC and
Clang. So if someone want the current behavior of eo_do_ret and
eo_do_super_ret, but in a nice way, he will just do a #define EFL_GNU
(or whatever we decide) before including Eo.h.
As we are heading to stabilize Eo API in EFL 1.15, I really would
prefer to get rid of this _ret variant.
I don't see why this ret variant is a problem. We could keep it there,
It is a very confusing one. You have to pass the variable you want it
to return stuff in. Once you are at the point of needing a variable,
well, ... why do you still need to use eo_do_ret ? Basically useless.
It's not useless, it's good for things like:
if (eo_do_ret(...))
but mostly for things like:
if (something)
else if (eo_do_ret(...))
or
if (something eo_do_ret(...))
You are missing a point here, you always have a useless variable
anyway in the parameter. So something like :
if (something)
{
int bob;
if (eo_do_ret(... bob ...))
Or something like that. Sure you can add this variable at the top of
your function, but that doesn't reduce how disturbing it is. Why do I
need a variable ? What does it do ? (That's rethorical question, but
having to read useless piece of code is lowering the quality of the
code by creating confusion.
there's no problem with that. It's useful for people want to write
portable code. For the different eo_do behaviour, we could have a define
that changes eo_do to the non portable version if we think it's really
needed. I don't really like the idea, but I don't object. Just offering
a better way of doing it. :)
I fail to see the difference with my proposal, but if you are fine
with it, then go.
I'm not fine and not not fine. I wanna see what people say. At the
moment, Daniel objects, you are in favour and I'm neutral.
Daniel objects to everything. I didn't answer is mail as there is no
argument in it. Objecting with no argument is clearly useless to a
discussion.
--
Cedric BAIL
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical virtual servers, alerts via email sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: Getting rid of eo_do_*ret
On 29/06/15 17:21, Cedric BAIL wrote:
On Mon, Jun 29, 2015 at 5:50 PM, Tom Hacohen t...@osg.samsung.com wrote:
On 29/06/15 15:53, Cedric BAIL wrote:
On Mon, Jun 29, 2015 at 4:18 PM, Tom Hacohen t...@osg.samsung.com wrote:
On 29/06/15 14:32, Cedric BAIL wrote:
I think that eo_do_ret and eo_do_super_ret are quite hugly to use and
unecessary. I think they should be gone. Their behavior can still be
nice to have especially inside efl tree. The reason they exist is that
we want to support other compiler than GCC and Clang for application
that use EFL. EFL itself can not be compiled by anything else than GCC
and Clang.
Maybe we should provide #if piece of code that will enable the old
non portable behavior of eo_do and eo_do_super for people who are sure
that there code should not be running on something else than GCC and
Clang. So if someone want the current behavior of eo_do_ret and
eo_do_super_ret, but in a nice way, he will just do a #define EFL_GNU
(or whatever we decide) before including Eo.h.
As we are heading to stabilize Eo API in EFL 1.15, I really would
prefer to get rid of this _ret variant.
I don't see why this ret variant is a problem. We could keep it there,
It is a very confusing one. You have to pass the variable you want it
to return stuff in. Once you are at the point of needing a variable,
well, ... why do you still need to use eo_do_ret ? Basically useless.
It's not useless, it's good for things like:
if (eo_do_ret(...))
but mostly for things like:
if (something)
else if (eo_do_ret(...))
or
if (something eo_do_ret(...))
You are missing a point here, you always have a useless variable
anyway in the parameter. So something like :
if (something)
{
int bob;
if (eo_do_ret(... bob ...))
Or something like that. Sure you can add this variable at the top of
your function, but that doesn't reduce how disturbing it is. Why do I
need a variable ? What does it do ? (That's rethorical question, but
having to read useless piece of code is lowering the quality of the
code by creating confusion.
I'm not missing the point. I've made my point. The purpose of the
variable is to work around standard c limitations. We could also get
around them with gnu extensions. I gave a few examples where it's useful.
there's no problem with that. It's useful for people want to write
portable code. For the different eo_do behaviour, we could have a define
that changes eo_do to the non portable version if we think it's really
needed. I don't really like the idea, but I don't object. Just offering
a better way of doing it. :)
I fail to see the difference with my proposal, but if you are fine
with it, then go.
I'm not fine and not not fine. I wanna see what people say. At the
moment, Daniel objects, you are in favour and I'm neutral.
Daniel objects to everything. I didn't answer is mail as there is no
argument in it. Objecting with no argument is clearly useless to a
discussion.
--
Tom.
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical virtual servers, alerts via email sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/elementary] master 01/01: Revert theme: return false if elm_object_style_set() failed to set requested style.
Hello.
On 29/06/15 08:49, Amitesh Singh wrote:
Hi
On Jun 29, 2015 12:15 PM, Stefan Schmidt ste...@osg.samsung.com wrote:
Hello.
On 29/06/15 07:32, Amitesh Singh wrote:
ami pushed a commit to branch master.
http://git.enlightenment.org/core/elementary.git/commit/?id=1a1aaec3c9f58c4a7408ccfc3e8a14cc607cfb58
commit 1a1aaec3c9f58c4a7408ccfc3e8a14cc607cfb58
Author: Amitesh Singh amitesh...@samsung.com
Date: Mon Jun 29 10:57:40 2015 +0530
Revert theme: return false if elm_object_style_set() failed to
set requested style.
This reverts commit 76004dfbec84664e253babc5bf576398a5901395.
We need to change other code also to accommodate this change.
_elm_theme_set should return an enum which tells what failed.
enum {
THEME_APPLY_FAILED,
THEME_DEFAULT_SUCCESS.
THEME_APPLY_SUCCESS
};
Based on that, we decide what needs to be done.
The above code will break the layout theme if incorrect theme are
passed.
It should be backported to Elm 1.14.
With full commit access this backport is something you can do yourself. :)
You are in the best position to decide if this patch needs to get into
the 1.14 stable updates and you are in the best position to fix it as
you already did for master.
Normally this means nothing else besides checking out the efl-1.14
branch, cherry-pick the commit id followed by compile and run time
testing.
Cool.. I will do it after running tests.
Thanks for sharing information.
Thanks.
If you have questions about this just ask.
regards
Stefan Schmidt
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical virtual servers, alerts via email sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Pre-release tarballs for efl and elm 1.14.2
Hello. On 28/06/15 12:33, Adrien Nader wrote: Just updated the website to point to these instead of 1.14.1. Many thanks for updating. Somehow I missed doing it this time. regards Stefan Schmidt -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/elementary] master 01/01: Revert theme: return false if elm_object_style_set() failed to set requested style.
Hello.
On 29/06/15 07:32, Amitesh Singh wrote:
ami pushed a commit to branch master.
http://git.enlightenment.org/core/elementary.git/commit/?id=1a1aaec3c9f58c4a7408ccfc3e8a14cc607cfb58
commit 1a1aaec3c9f58c4a7408ccfc3e8a14cc607cfb58
Author: Amitesh Singh amitesh...@samsung.com
Date: Mon Jun 29 10:57:40 2015 +0530
Revert theme: return false if elm_object_style_set() failed to set
requested style.
This reverts commit 76004dfbec84664e253babc5bf576398a5901395.
We need to change other code also to accommodate this change.
_elm_theme_set should return an enum which tells what failed.
enum {
THEME_APPLY_FAILED,
THEME_DEFAULT_SUCCESS.
THEME_APPLY_SUCCESS
};
Based on that, we decide what needs to be done.
The above code will break the layout theme if incorrect theme are passed.
It should be backported to Elm 1.14.
With full commit access this backport is something you can do yourself. :)
You are in the best position to decide if this patch needs to get into
the 1.14 stable updates and you are in the best position to fix it as
you already did for master.
Normally this means nothing else besides checking out the efl-1.14
branch, cherry-pick the commit id followed by compile and run time testing.
regards
Stefan Schmidt
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical virtual servers, alerts via email sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Weekly news from the automated build and QA front
Hello. Summary: o Nightly builds are back and have examples enabled for efl now. o The number of patches which need review has reduced. This should give everyone an overview over what has happened in the last week on the QA front. The numbers in parentheses reflect the values from last week to give you a trend. CI: o Overall build statistic: 7.65% (8.09%) failed. https://build.enlightenment.org/ Unique Jenkins build failures: o Open: o Resolved: Clang build problem with eolian_cxx: https://build.enlightenment.org/job/changely_efl_clang_x86/3464/console Unconditional ecore_buffer example build: https://build.enlightenment.org/view/Nightly/job/nightly_efl_gcc_x86_64/899/console Clang scan-build: o EFL scan-build reports N/A (N/A) issues. https://build.enlightenment.org/job/nightly_efl_clang_x86_64/lastSuccessfu lBuild/artifact/scan-build/build/ o Elementary scan-build reports 88 (85) issues. https://build.enlightenment.org/job/nightly_elm_clang_x86_64/lastSuccessfulBuild/artifact/scan-build/build Unit tests: o 522 (518) unit tests for efl and none failing Coverage: o EFL total coverage is at 36.3% (36.3%) lines and 39.5% (39.5%) functions https://build.enlightenment.org/view/Test%20Coverage/ Coverity: o EFL: Outstanding defects 85 (82) with a density of 0.11 (0.11) o Elm: Outstanding defects 12 (9) with a density of 0.05 (0.04) o Evas Generic Loaders: Outstanding defects 2 (2) with a density of 0.02 (0.02) o Emotion Generic Players: Outstanding defects 0 (0) with a density of 0 (0) o Enlightenment: Outstanding defects 51 (53) with a density of 0.19 (0.19) o Terminology: Outstanding defects 0 (0) with a density of 0 (0) o Rage: Outstanding defects 0 (0) with a density of 0 (0) Phab: o Total bug count: 636 (637) https://phab.enlightenment.org/maniphest/report/burn/ o Pending patch reviews: 79 (95) regards Stefan Schmidt -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Intent to freeze
Hello. On 28/06/15 06:40, Carsten Haitzler wrote: On Sat, 27 Jun 2015 09:05:02 -0400 Christopher Michael cpmich...@osg.samsung.com said: On 06/27/2015 01:14 AM, Carsten Haitzler wrote: On Fri, 26 Jun 2015 16:11:45 -0400 Mike Blumenkrantz michael.blumenkra...@gmail.com said: With a few minor exceptions in Wayland, all target features for the E20 release have been met. As such, I am planning to commence an everything-but-wayland feature freeze on Friday, 3 July 2015. If anyone has things that they want to push in or implement before the freeze begins, I'm open to moving back the date as necessary--within reason. I will not, however, be very receptive to adding new features once the release cycle freeze has begun. actually - devilhorns. you need to pipe in here - what is the wayland state, and what would there be left to drop in after july 3 and what timetable? As far as what is left: DnD needs a bit of testing/tweaking yet as there are some little buggers floating in there (I'll be hacking on that come Monday). We have pending patches to support wl_text_input and wl_input_method (https://phab.enlightenment.org/D2275) however we cannot securely push those until we have a working VKbd implementation to go with them. I pinged shiin to see if he could also hack up a vkbd to go with. While not a Top priority, support for wl_scaler and wl_viewport would be remaining things to drop in after July 3. We have pending patches for that also (https://phab.enlightenment.org/D2485) however those need some refactoring. i am saying this from the perspective that we get a fair number of does e run wayland yet kind of questions and the answer is always nebulous. i think we want a clear state of play for an e20 release. While I have not tested it yet, Mike has updated/refactored my initial XWayland branch and pushed that upstream already which means we should have working XWayland support now. I've not tested it yet myself however he did manage to get Firefox running with it (which is good news) :) E/Elm apps are running good in E-Wl. Gtk apps also (tho Some gtk apps have popup menu placement issues according to Phab reports). I don't suspect that those are Major issues and likely will take little time to fix. QT apps on the other hand are a whole different can of worms. Apparenly, QT5 has not been updated yet to support xdg_shell version 5 which means, while the apps do run, they have quite a few issues. I spoke with RzR about it and he plans to update QT5 to support xdg_shell version 5 which should address issues there. There are a few pending buggers listed on Phab which I/we will be addressing in the coming weeks tho I don't think any of them are Major problems (in terms of functionality). It is likely that I may be forgetting something in this list, so if you can think of something I may have missed, please ask. the question reading between the lines from users is: can i now use E20 to switch to wayland? :) i've talked with you about this - i know that i personally can't. my 2 main desktop systems have new nvidia rigs and literally have zero nouveau support. i know i'm not the only one and for many nouveau is still iffy. i am sure we could get more people working on wayland if we could run e in a window in x11 - ie wl-x11. like weston does. with a but of imagination it'd be possible to get full acceleration for egl working too. from a pr point of view, for many people they'd like to see how e wayland is going without having to drop out of x11 to do it. this'd help answer a lot of questions people have. :) it'd also mean a LOT more helping getting wayland moving along. btw - how goes session recovering with uuid's etc. ... stefan? The uuid store is in for some time. I have branch with a wayland protocol extension to pass the uuid arround which I can push in later today or tomorrow. What is still missing the re-connect handling, keeping apps alive and making sure they come back correctly when the compositor comes back. As I will be mostly offline for the next three weeks starting from tomorrow afternoon this has to wait until beginning of August. Given this is wayland only right now it should be within the scope for wayland fixes in the freeze. EFL 1.15 needs to be out before e20 in any case. regards Stefan Schmidt -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/elementary] master 01/01: Revert theme: return false if elm_object_style_set() failed to set requested style.
Hi
On Jun 29, 2015 12:15 PM, Stefan Schmidt ste...@osg.samsung.com wrote:
Hello.
On 29/06/15 07:32, Amitesh Singh wrote:
ami pushed a commit to branch master.
http://git.enlightenment.org/core/elementary.git/commit/?id=1a1aaec3c9f58c4a7408ccfc3e8a14cc607cfb58
commit 1a1aaec3c9f58c4a7408ccfc3e8a14cc607cfb58
Author: Amitesh Singh amitesh...@samsung.com
Date: Mon Jun 29 10:57:40 2015 +0530
Revert theme: return false if elm_object_style_set() failed to
set requested style.
This reverts commit 76004dfbec84664e253babc5bf576398a5901395.
We need to change other code also to accommodate this change.
_elm_theme_set should return an enum which tells what failed.
enum {
THEME_APPLY_FAILED,
THEME_DEFAULT_SUCCESS.
THEME_APPLY_SUCCESS
};
Based on that, we decide what needs to be done.
The above code will break the layout theme if incorrect theme are
passed.
It should be backported to Elm 1.14.
With full commit access this backport is something you can do yourself. :)
You are in the best position to decide if this patch needs to get into
the 1.14 stable updates and you are in the best position to fix it as
you already did for master.
Normally this means nothing else besides checking out the efl-1.14
branch, cherry-pick the commit id followed by compile and run time
testing.
Cool.. I will do it after running tests.
Thanks for sharing information.
regards
Stefan Schmidt
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical virtual servers, alerts via email sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical virtual servers, alerts via email sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [admin/devs] master 01/01: Let's welcome SangHyeon Lee !
I really appriciate your great support, Mr Daniel. All the thing that I had done in here couldn't possible without you. It's great pleasure to contribute my little talent on EFL community but also I feel shame about my lack of skills and knowledges. I understand this permission is some kind of whip 'do best as you can'! So I'll never forget the words of Daniel and always try to do my best. Thanks to cedric about nomination. Thanks to my best chat friends and great adviser Ami(and again united will be win the next premier league ;-) ramos on comming!!) Thanks to All the other seniors in samsung and EFL community. Let's have fun! 2015. 6. 30. 오전 12:59에 Daniel Juyung Seo seojuyu...@gmail.com님이 작성: Congratulations! I hope you will do a distinguishable contributions to EFL community with the permission! With great power comes great responsibility! Thanks, Daniel Juyung Seo (SeoZ) On Mon, Jun 29, 2015 at 10:15 PM, Cedric BAIL ced...@osg.samsung.com wrote: cedric pushed a commit to branch master. http://git.enlightenment.org/admin/devs.git/commit/?id=f8b183af688025feb4a3c5cfb43c00ccf4ceab88 commit f8b183af688025feb4a3c5cfb43c00ccf4ceab88 Author: Cedric BAIL ced...@osg.samsung.com Date: Mon Jun 29 15:15:00 2015 +0200 Let's welcome SangHyeon Lee ! --- developers/sanghyeonlee/id_rsa.pub | 1 + developers/sanghyeonlee/info.txt | 10 ++ 2 files changed, 11 insertions(+) diff --git a/developers/sanghyeonlee/id_rsa.pub b/developers/sanghyeonlee/id_rsa.pub new file mode 100644 index 000..694d3bc --- /dev/null +++ b/developers/sanghyeonlee/id_rsa.pub @@ -0,0 +1 @@ +ssh-rsa B3NzaC1yc2EDAQABAAABAQClq5KwmQn5pFILPDyMxoek6lxpR2uAzD47kqZ1sfRKlG980vmBEJosg5Wwt6wg8rKvoAt0e3tcU6WngOvNLstwFkBVvGl9VXKwKvUOEEN5nwcjUBKw337B3xjQm9Iwe5XFVJW6tgE2woPYSFJ3XFqxmMxSQBPNYC2WGrniFAfCUwPaOmtz0jby9DfuzOXtH6smo9+WU0qaDquNl/DCnkKPBhCT6J/8uEGiDlxnbW+z3dBOpkoUfKPWz8UgWf11QYMk/qbLcnnADBp+NBJPQormARmf+8fM+Z9Td90VXVrAsVUV8ej1VQNVcpx6svIpOpFxlmZES6fDC33NlOQ/N8fL sh10233lee@sh10233lee-linux diff --git a/developers/sanghyeonlee/info.txt b/developers/sanghyeonlee/info.txt new file mode 100644 index 000..ff93ca9 --- /dev/null +++ b/developers/sanghyeonlee/info.txt @@ -0,0 +1,10 @@ +Login:SanghyeonLee +IRC Nick: Jade_L +Name: SangHyeon Lee +Location: Suwon, Korea +E-Mail: dltkdgus1...@gmail.com, sh10233@samsung.com +Managing: elementary(genlist,gengrid) +Contributing: efl, elementary +Group:Core, Libraries, Applications +Platform: Ubuntu(Linux), Tizen(Linux), Windows +GeoData: 37.257920, 127.059776 -- -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Intent to freeze
On Mon, 29 Jun 2015 12:28:57 +0200 Stefan Schmidt ste...@osg.samsung.com said: Hello. On 29/06/15 11:43, Carsten Haitzler wrote: On Mon, 29 Jun 2015 09:06:14 +0200 Stefan Schmidt ste...@osg.samsung.com said: Hello. On 28/06/15 06:40, Carsten Haitzler wrote: On Sat, 27 Jun 2015 09:05:02 -0400 Christopher Michael cpmich...@osg.samsung.com said: On 06/27/2015 01:14 AM, Carsten Haitzler wrote: On Fri, 26 Jun 2015 16:11:45 -0400 Mike Blumenkrantz michael.blumenkra...@gmail.com said: With a few minor exceptions in Wayland, all target features for the E20 release have been met. As such, I am planning to commence an everything-but-wayland feature freeze on Friday, 3 July 2015. If anyone has things that they want to push in or implement before the freeze begins, I'm open to moving back the date as necessary--within reason. I will not, however, be very receptive to adding new features once the release cycle freeze has begun. actually - devilhorns. you need to pipe in here - what is the wayland state, and what would there be left to drop in after july 3 and what timetable? As far as what is left: DnD needs a bit of testing/tweaking yet as there are some little buggers floating in there (I'll be hacking on that come Monday). We have pending patches to support wl_text_input and wl_input_method (https://phab.enlightenment.org/D2275) however we cannot securely push those until we have a working VKbd implementation to go with them. I pinged shiin to see if he could also hack up a vkbd to go with. While not a Top priority, support for wl_scaler and wl_viewport would be remaining things to drop in after July 3. We have pending patches for that also (https://phab.enlightenment.org/D2485) however those need some refactoring. i am saying this from the perspective that we get a fair number of does e run wayland yet kind of questions and the answer is always nebulous. i think we want a clear state of play for an e20 release. While I have not tested it yet, Mike has updated/refactored my initial XWayland branch and pushed that upstream already which means we should have working XWayland support now. I've not tested it yet myself however he did manage to get Firefox running with it (which is good news) :) E/Elm apps are running good in E-Wl. Gtk apps also (tho Some gtk apps have popup menu placement issues according to Phab reports). I don't suspect that those are Major issues and likely will take little time to fix. QT apps on the other hand are a whole different can of worms. Apparenly, QT5 has not been updated yet to support xdg_shell version 5 which means, while the apps do run, they have quite a few issues. I spoke with RzR about it and he plans to update QT5 to support xdg_shell version 5 which should address issues there. There are a few pending buggers listed on Phab which I/we will be addressing in the coming weeks tho I don't think any of them are Major problems (in terms of functionality). It is likely that I may be forgetting something in this list, so if you can think of something I may have missed, please ask. the question reading between the lines from users is: can i now use E20 to switch to wayland? :) i've talked with you about this - i know that i personally can't. my 2 main desktop systems have new nvidia rigs and literally have zero nouveau support. i know i'm not the only one and for many nouveau is still iffy. i am sure we could get more people working on wayland if we could run e in a window in x11 - ie wl-x11. like weston does. with a but of imagination it'd be possible to get full acceleration for egl working too. from a pr point of view, for many people they'd like to see how e wayland is going without having to drop out of x11 to do it. this'd help answer a lot of questions people have. :) it'd also mean a LOT more helping getting wayland moving along. btw - how goes session recovering with uuid's etc. ... stefan? The uuid store is in for some time. I have branch with a wayland protocol extension to pass the uuid arround which I can push in later today or tomorrow. What is still missing the re-connect handling, keeping apps alive and making sure they come back correctly when the compositor comes back. thats a necessary part of the uuid thing. it needs all of these done to be done: 1. store of uuids that survives e segs/restarts correctly (tho not logout/in) Its a mmaped object named /e_uuid_store and E checks for it during start/restart. What information will be applied is policy and part of #4. 2. protocol to assign uuids and pass them around back to comp That is what I will put in today or tomorrow. 3. reconnect code that correctly uses assigned uuids I played around with that but did not had it working so far. That is the bigger part of what is missing. 4. code to restore state of
Re: [E-devel] Fwd: Getting rid of eo_do_*ret
On Mon, 29 Jun 2015 17:34:26 +0100 Tom Hacohen t...@osg.samsung.com said:
On 29/06/15 17:21, Cedric BAIL wrote:
On Mon, Jun 29, 2015 at 5:50 PM, Tom Hacohen t...@osg.samsung.com wrote:
On 29/06/15 15:53, Cedric BAIL wrote:
On Mon, Jun 29, 2015 at 4:18 PM, Tom Hacohen t...@osg.samsung.com wrote:
On 29/06/15 14:32, Cedric BAIL wrote:
I think that eo_do_ret and eo_do_super_ret are quite hugly to use and
unecessary. I think they should be gone. Their behavior can still be
nice to have especially inside efl tree. The reason they exist is that
we want to support other compiler than GCC and Clang for application
that use EFL. EFL itself can not be compiled by anything else than GCC
and Clang.
Maybe we should provide #if piece of code that will enable the old
non portable behavior of eo_do and eo_do_super for people who are sure
that there code should not be running on something else than GCC and
Clang. So if someone want the current behavior of eo_do_ret and
eo_do_super_ret, but in a nice way, he will just do a #define EFL_GNU
(or whatever we decide) before including Eo.h.
As we are heading to stabilize Eo API in EFL 1.15, I really would
prefer to get rid of this _ret variant.
I don't see why this ret variant is a problem. We could keep it there,
It is a very confusing one. You have to pass the variable you want it
to return stuff in. Once you are at the point of needing a variable,
well, ... why do you still need to use eo_do_ret ? Basically useless.
It's not useless, it's good for things like:
if (eo_do_ret(...))
but mostly for things like:
if (something)
else if (eo_do_ret(...))
or
if (something eo_do_ret(...))
You are missing a point here, you always have a useless variable
anyway in the parameter. So something like :
if (something)
{
int bob;
if (eo_do_ret(... bob ...))
Or something like that. Sure you can add this variable at the top of
your function, but that doesn't reduce how disturbing it is. Why do I
need a variable ? What does it do ? (That's rethorical question, but
having to read useless piece of code is lowering the quality of the
code by creating confusion.
I'm not missing the point. I've made my point. The purpose of the
variable is to work around standard c limitations. We could also get
around them with gnu extensions. I gave a few examples where it's useful.
i'm going to go back to my hated proposal... we add a better CPP in front of
CPP. use ecc instead of gcc or clang etc. (and ecc will parse/process and
generate new c code that then is passed to $CC - much like ccache or distcc).
this will solve all such problems. :)
there's no problem with that. It's useful for people want to write
portable code. For the different eo_do behaviour, we could have a define
that changes eo_do to the non portable version if we think it's really
needed. I don't really like the idea, but I don't object. Just offering
a better way of doing it. :)
I fail to see the difference with my proposal, but if you are fine
with it, then go.
I'm not fine and not not fine. I wanna see what people say. At the
moment, Daniel objects, you are in favour and I'm neutral.
Daniel objects to everything. I didn't answer is mail as there is no
argument in it. Objecting with no argument is clearly useless to a
discussion.
--
Tom.
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical virtual servers, alerts via email sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
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
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [admin/devs] master 01/01: Let's welcome SangHyeon Lee !
Dont feel shameful. You deserve it. If you still think you are not enough to have this permission, now you have a permission to rvert this patch. hhahahaha LOL Anyways you deserve it! On Tue, Jun 30, 2015, 10:25 AM 이상현 dltkdgus1...@gmail.com wrote: I really appriciate your great support, Mr Daniel. All the thing that I had done in here couldn't possible without you. It's great pleasure to contribute my little talent on EFL community but also I feel shame about my lack of skills and knowledges. I understand this permission is some kind of whip 'do best as you can'! So I'll never forget the words of Daniel and always try to do my best. Thanks to cedric about nomination. Thanks to my best chat friends and great adviser Ami(and again united will be win the next premier league ;-) ramos on comming!!) Thanks to All the other seniors in samsung and EFL community. Let's have fun! 2015. 6. 30. 오전 12:59에 Daniel Juyung Seo seojuyu...@gmail.com님이 작성: Congratulations! I hope you will do a distinguishable contributions to EFL community with the permission! With great power comes great responsibility! Thanks, Daniel Juyung Seo (SeoZ) On Mon, Jun 29, 2015 at 10:15 PM, Cedric BAIL ced...@osg.samsung.com wrote: cedric pushed a commit to branch master. http://git.enlightenment.org/admin/devs.git/commit/?id=f8b183af688025feb4a3c5cfb43c00ccf4ceab88 commit f8b183af688025feb4a3c5cfb43c00ccf4ceab88 Author: Cedric BAIL ced...@osg.samsung.com Date: Mon Jun 29 15:15:00 2015 +0200 Let's welcome SangHyeon Lee ! --- developers/sanghyeonlee/id_rsa.pub | 1 + developers/sanghyeonlee/info.txt | 10 ++ 2 files changed, 11 insertions(+) diff --git a/developers/sanghyeonlee/id_rsa.pub b/developers/sanghyeonlee/id_rsa.pub new file mode 100644 index 000..694d3bc --- /dev/null +++ b/developers/sanghyeonlee/id_rsa.pub @@ -0,0 +1 @@ +ssh-rsa B3NzaC1yc2EDAQABAAABAQClq5KwmQn5pFILPDyMxoek6lxpR2uAzD47kqZ1sfRKlG980vmBEJosg5Wwt6wg8rKvoAt0e3tcU6WngOvNLstwFkBVvGl9VXKwKvUOEEN5nwcjUBKw337B3xjQm9Iwe5XFVJW6tgE2woPYSFJ3XFqxmMxSQBPNYC2WGrniFAfCUwPaOmtz0jby9DfuzOXtH6smo9+WU0qaDquNl/DCnkKPBhCT6J/8uEGiDlxnbW+z3dBOpkoUfKPWz8UgWf11QYMk/qbLcnnADBp+NBJPQormARmf+8fM+Z9Td90VXVrAsVUV8ej1VQNVcpx6svIpOpFxlmZES6fDC33NlOQ/N8fL sh10233lee@sh10233lee-linux diff --git a/developers/sanghyeonlee/info.txt b/developers/sanghyeonlee/info.txt new file mode 100644 index 000..ff93ca9 --- /dev/null +++ b/developers/sanghyeonlee/info.txt @@ -0,0 +1,10 @@ +Login:SanghyeonLee +IRC Nick: Jade_L +Name: SangHyeon Lee +Location: Suwon, Korea +E-Mail: dltkdgus1...@gmail.com, sh10233@samsung.com +Managing: elementary(genlist,gengrid) +Contributing: efl, elementary +Group:Core, Libraries, Applications +Platform: Ubuntu(Linux), Tizen(Linux), Windows +GeoData: 37.257920, 127.059776 -- -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [admin/devs] master 01/01: Let's welcome SangHyeon Lee !
Please stop it, you will make me blubber!!! :P On Tue, 30 Jun 2015 02:39:58 + Daniel Juyung Seo seojuyu...@gmail.com wrote: Dont feel shameful. You deserve it. If you still think you are not enough to have this permission, now you have a permission to rvert this patch. hhahahaha LOL Anyways you deserve it! On Tue, Jun 30, 2015, 10:25 AM 이상현 dltkdgus1...@gmail.com wrote: I really appriciate your great support, Mr Daniel. All the thing that I had done in here couldn't possible without you. It's great pleasure to contribute my little talent on EFL community but also I feel shame about my lack of skills and knowledges. I understand this permission is some kind of whip 'do best as you can'! So I'll never forget the words of Daniel and always try to do my best. Thanks to cedric about nomination. Thanks to my best chat friends and great adviser Ami(and again united will be win the next premier league ;-) ramos on comming!!) Thanks to All the other seniors in samsung and EFL community. Let's have fun! 2015. 6. 30. 오전 12:59에 Daniel Juyung Seo seojuyu...@gmail.com님이 작성: Congratulations! I hope you will do a distinguishable contributions to EFL community with the permission! With great power comes great responsibility! Thanks, Daniel Juyung Seo (SeoZ) On Mon, Jun 29, 2015 at 10:15 PM, Cedric BAIL ced...@osg.samsung.com wrote: cedric pushed a commit to branch master. http://git.enlightenment.org/admin/devs.git/commit/?id=f8b183af688025feb4a3c5cfb43c00ccf4ceab88 commit f8b183af688025feb4a3c5cfb43c00ccf4ceab88 Author: Cedric BAIL ced...@osg.samsung.com Date: Mon Jun 29 15:15:00 2015 +0200 Let's welcome SangHyeon Lee ! --- developers/sanghyeonlee/id_rsa.pub | 1 + developers/sanghyeonlee/info.txt | 10 ++ 2 files changed, 11 insertions(+) diff --git a/developers/sanghyeonlee/id_rsa.pub b/developers/sanghyeonlee/id_rsa.pub new file mode 100644 index 000..694d3bc --- /dev/null +++ b/developers/sanghyeonlee/id_rsa.pub @@ -0,0 +1 @@ +ssh-rsa B3NzaC1yc2EDAQABAAABAQClq5KwmQn5pFILPDyMxoek6lxpR2uAzD47kqZ1sfRKlG980vmBEJosg5Wwt6wg8rKvoAt0e3tcU6WngOvNLstwFkBVvGl9VXKwKvUOEEN5nwcjUBKw337B3xjQm9Iwe5XFVJW6tgE2woPYSFJ3XFqxmMxSQBPNYC2WGrniFAfCUwPaOmtz0jby9DfuzOXtH6smo9+WU0qaDquNl/DCnkKPBhCT6J/8uEGiDlxnbW+z3dBOpkoUfKPWz8UgWf11QYMk/qbLcnnADBp+NBJPQormARmf+8fM+Z9Td90VXVrAsVUV8ej1VQNVcpx6svIpOpFxlmZES6fDC33NlOQ/N8fL sh10233lee@sh10233lee-linux diff --git a/developers/sanghyeonlee/info.txt b/developers/sanghyeonlee/info.txt new file mode 100644 index 000..ff93ca9 --- /dev/null +++ b/developers/sanghyeonlee/info.txt @@ -0,0 +1,10 @@ +Login:SanghyeonLee +IRC Nick: Jade_L +Name: SangHyeon Lee +Location: Suwon, Korea +E-Mail: dltkdgus1...@gmail.com, sh10233@samsung.com +Managing: elementary(genlist,gengrid) +Contributing: efl, elementary +Group:Core, Libraries, Applications +Platform: Ubuntu(Linux), Tizen(Linux), Windows +GeoData: 37.257920, 127.059776 -- -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
