Re: [E-devel] New emails for every b0rker
On 16/09/2013 19:51, Bertrand Jacquin wrote: Ladies, Everyone of you having commit access, also seems to be called developers does now have an email @enlightenment.org. Emails send to a developer is then forwarded to emails you have declared in the E-Mail: info.txt pattern. Only valid email are processed (meaning not starting with a dash (minus ?)), one or more is accepted. So be carefull about what email you have registered (isn't it dan ;). Change in that file is learn every 15 minutes. So this work for domain enlightenment.org, efl.so and libefl.so Your dear spam source, Report every issue and claims here or in the phab Admin project. Hello, I can't make it to work. Tried sending mails to k...@enlightenment.org, k...@efl.so and k...@libefl.so without success. Do i need to b0rk core/efl do get it active ? =) Maybe my info.txt doesnt respect parsing you made. <>-- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/01: Reset window opaque region on 180 degree flips also.
devilhorns pushed a commit to branch master. commit 592076e319062a1b8a301f9f3deea45440ae456f Author: Chris Michael Date: Tue Sep 17 08:27:15 2013 +0100 Reset window opaque region on 180 degree flips also. Signed-off-by: Chris Michael --- src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c index eee881c..15bb93c 100644 --- a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c +++ b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c @@ -416,6 +416,12 @@ _rotation_do(Ecore_Evas *ee, int rotation, int resize) /* record the current rotation of the ecore_evas */ ee->rotation = rotation; +ecore_wl_window_opaque_region_set(wdata->win, + wdata->win->opaque.x, + wdata->win->opaque.y, + wdata->win->opaque.w, + wdata->win->opaque.h); + /* send a mouse_move process * * NB: Is This Really Needed ?? */ --
Re: [E-devel] [EGIT] [core/elementary] master 01/02: Remove __UNUSED__ from function declaration where parameter is actually used.
Hello. On 09/17/2013 07:44 AM, Chris Michael - Enlightenment Git wrote: > devilhorns pushed a commit to branch master. > > commit 64bc97c53c5c3772595f9d2321f9e19590d8a477 > Author: Chris Michael > Date: Mon Sep 16 11:40:30 2013 +0100 > > Remove __UNUSED__ from function declaration where parameter is > actually used. This brings an old topic back into my mind. Its not the first time we eagerly tagged parameters as unused because gcc warned about it and later started to use them without removing the unused label. This has the potential to screw us badly as it is up to the compiler to decide what to do with the parameter here. Given how many callback and other signatures we have with user_data or other unused parameters we end up with 3630 EINA_UNUSED and even 71 __UNUSED__ in efl alone. All with the potential to be used at some point but forgotten to remove the label. My proposal would be to use -Wno-unused-parameter in our CFLAGS to disable this warning and remove all EINA_UNUSED and __UNUSED__ from parameters. I know it has the downside that in the rare case where you add a parameter to a signature yourself (read: not using an existing function signature) you might add it and forgot to use it. Which will not reported as warning in this case. In my opinion the risk is higher than the benefit here. I expect people to have a different opinion on this and get really angry if I just start to add the CFLAG and remove all EINA_UNSED from parameter so I thought I bring it up here to get some opinions. We normally have plenty of opinions around. :) regards Stefan Schmidt -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [admin/devs] master 01/01: Update my info.txt
captainigloo pushed a commit to branch master. commit d05d7ae0d6eef22cfd28109f46ec061289e44ac9 Author: Nicolas Aguirre Date: Tue Sep 17 10:12:56 2013 +0200 Update my info.txt --- captainigloo/info.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/captainigloo/info.txt b/captainigloo/info.txt index cbe0394..597180e 100644 --- a/captainigloo/info.txt +++ b/captainigloo/info.txt @@ -3,10 +3,10 @@ IRC Nick: captainigloo Cloak:developer/captainigloo Name: Nicolas Aguirre Location: Toulouse, France -E-Mail: -aguirre.nico...@gmail.com +E-Mail: aguirre.nico...@gmail.com WWW: http://dev.enlightenment.fr/~captainigloo/ -Managing: enna-explorer, elfe +Managing: elfe, calaos, enna Contributing: Elementary Group: Applications -Platform: Bodhilinux (Linux), MacOSX Lion +Platform: Arch Linux GeoData: 43.598816 1.436257 --
Re: [E-devel] [EGIT] [core/elementary] master 01/01: elementary: allow custom text part on item list
Sorry, but I don't finish my work to support theme change with customized
text part.
I will update changelog and news when I push this work. Surely tonight or
tomorrow.
2013/9/17 ChunEon Park
> conceptually this is acceptable to me, already all widgets support this
> kind of customized text set.
>
>
> -Regards, Hermet-
>
> -Original Message-
> From: "Michaël Bouchaud"
> To: "Enlightenment developer list"<
> enlightenment-devel@lists.sourceforge.net>;
> Cc: ;
> Sent: 2013-09-16 (월) 22:14:56
> Subject: Re: [E-devel] [EGIT] [core/elementary] master 01/01: elementary:
> allow custom text part on item list
>
> Of course, I can check this. I will try to do it before tonight and fix it.
>
>
> 2013/9/16 Daniel Juyung Seo @gmail.com>
>
> > Hello Michael Bouchaud,
> > does this really work?
> >
> > It's likely this works only in a very rare cases.
> > It will be broken in many cases, especially theme change will break this.
> > The label inside the list is managed by elm_list and it'll set the label
> > when the theme is changed.
> > And so on...
> >
> > Can you check this?
> >
> > Daniel Juyung Seo (SeoZ)
> >
> >
> > On Mon, Sep 16, 2013 at 7:20 PM, Michaël Bouchaud - Enlightenment Git <
> > no-re...@enlightenment.org> wrote:
> >
> > > yoz pushed a commit to branch master.
> > >
> > > commit 5414fdba3c874451b43e0994df897bb3705b1f2d
> > > Author: Michaël Bouchaud (yoz) @efl.so>
> > > Date: Mon Sep 16 12:18:24 2013 +0200
> > >
> > > elementary: allow custom text part on item list
> > > ---
> > > src/lib/elm_list.c 6 +-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/src/lib/elm_list.c b/src/lib/elm_list.c
> > > index e193fdf..72d3e9f 100644
> > > --- a/src/lib/elm_list.c
> > > +++ b/src/lib/elm_list.c
> > > @@ -1405,7 +1405,11 @@ _item_text_set_hook(Elm_Object_Item *it,
> > > {
> > > Elm_List_Item *list_it = (Elm_List_Item *)it;
> > >
> > > - if (part && strcmp(part, "default")) return;
> > > + if (part && strcmp(part, "default"))
> > > + {
> > > +edje_object_part_text_escaped_set(VIEW(list_it), part, text);
> > > +return;
> > > + }
> > > if (!eina_stringshare_replace(&list_it->label, text)) return;
> > > if (VIEW(list_it))
> > > edje_object_part_text_escaped_set(VIEW(list_it), "elm.text",
> text);
> > >
> > > --
> > >
> > >
> > >
> >
> >
> --
> > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> > SharePoint
> > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> > includes
> > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
>
>
> --
> Michaël Bouchaud (yoz) @efl.so>
>
> --
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
> --
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Michaël Bouchaud (yoz)
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
___
Re: [E-devel] [EGIT] [core/elementary] master 01/02: Remove __UNUSED__ from function declaration where parameter is actually used.
On 17/09/13 08:30, Stefan Schmidt wrote: > Hello. > > On 09/17/2013 07:44 AM, Chris Michael - Enlightenment Git wrote: >> devilhorns pushed a commit to branch master. >> >> commit 64bc97c53c5c3772595f9d2321f9e19590d8a477 >> Author: Chris Michael >> Date: Mon Sep 16 11:40:30 2013 +0100 >> >> Remove __UNUSED__ from function declaration where parameter is >> actually used. > > This brings an old topic back into my mind. > > Its not the first time we eagerly tagged parameters as unused because > gcc warned about it and later started to use them without removing the > unused label. This has the potential to screw us badly as it is up to > the compiler to decide what to do with the parameter here. > > Given how many callback and other signatures we have with user_data or > other unused parameters we end up with 3630 EINA_UNUSED and even 71 > __UNUSED__ in efl alone. All with the potential to be used at some point > but forgotten to remove the label. > > My proposal would be to use -Wno-unused-parameter in our CFLAGS to > disable this warning and remove all EINA_UNUSED and __UNUSED__ from > parameters. > > I know it has the downside that in the rare case where you add a > parameter to a signature yourself (read: not using an existing function > signature) you might add it and forgot to use it. Which will not > reported as warning in this case. > > In my opinion the risk is higher than the benefit here. > > I expect people to have a different opinion on this and get really angry > if I just start to add the CFLAG and remove all EINA_UNSED from > parameter so I thought I bring it up here to get some opinions. We > normally have plenty of opinions around. :) > > regards > Stefan Schmidt > First, all I can say is Wow !! One of my commits has actually brought about Constructive criticism for a change :P That being said, I would have to agree with you on this. While (EINA_)UNUSED is nice, it's actual benefit is negligible when people do not (or forget to) remove the UNUSED at a later date when things are used. Potentially leading to the compiler making an incorrect decision. Although, on the other hand I don't see -Wno-unused-parameter as being Ideal either (as you mentioned above with not reported warnings) On a personal level, I would be ok with either approach. However, if we do stick with (EINA_)UNUSED, then I think that people just need to be more diligent when they modify functions/code. Cheers, dh -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/01: EvasGL: Fixed a bug where the wrong data variable to buffer alloc func.
sung pushed a commit to branch master.
commit b9e3e6be57e178ce83433447bbaf79fbbda0f653
Author: Sung W. Park
Date: Tue Sep 17 17:22:26 2013 +0900
EvasGL: Fixed a bug where the wrong data variable to buffer alloc func.
It's an optional feature so it's not automatically turned on but
would have caused a segfault somewhere. Somehow slipped notice
but fixed now.
---
src/modules/evas/engines/gl_common/evas_gl_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/modules/evas/engines/gl_common/evas_gl_core.c
b/src/modules/evas/engines/gl_common/evas_gl_core.c
index 5ae7a9e..c711a26 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_core.c
+++ b/src/modules/evas/engines/gl_common/evas_gl_core.c
@@ -1695,7 +1695,7 @@ evgl_make_current(void *eng_data, EVGL_Surface *sfc,
EVGL_Context *ctx)
// Destroy created resources
if (sfc->buffers_allocated)
{
- if (!_surface_buffers_allocate(evgl_engine, sfc, 0, 0, 1))
+ if (!_surface_buffers_allocate(eng_data, sfc, 0, 0, 1))
{
ERR("Unable to destroy surface buffers!");
return 0;
@@ -1708,7 +1708,7 @@ evgl_make_current(void *eng_data, EVGL_Surface *sfc,
EVGL_Context *ctx)
// Create internal buffers if not yet created
if (!sfc->buffers_allocated)
{
- if (!_surface_buffers_allocate(evgl_engine, sfc, sfc->w,
sfc->h, 1))
+ if (!_surface_buffers_allocate(eng_data, sfc, sfc->w,
sfc->h, 1))
{
ERR("Unable Create Specificed Surfaces. Unsupported
format!");
return 0;
--
Re: [E-devel] [EGIT] [core/elementary] master 01/02: Remove __UNUSED__ from function declaration where parameter is actually used.
Hi,
I'm for the replacement of
#define EINA_UNUSED __attribute__ ((__unused__))
with
#define EINA_UNUSED(var) do { (void)(var); } while (0)
so that
- fcts prototypes are never touched
- compiler warnings can be silenced in function definitions
Jérémy
On Tuesday 17 September 2013 08:30, Stefan Schmidt wrote :
> Hello.
>
> On 09/17/2013 07:44 AM, Chris Michael - Enlightenment Git wrote:
> > devilhorns pushed a commit to branch master.
> >
> > commit 64bc97c53c5c3772595f9d2321f9e19590d8a477
> > Author: Chris Michael
> > Date: Mon Sep 16 11:40:30 2013 +0100
> >
> > Remove __UNUSED__ from function declaration where parameter is
> > actually used.
>
> This brings an old topic back into my mind.
>
> Its not the first time we eagerly tagged parameters as unused because
> gcc warned about it and later started to use them without removing the
> unused label. This has the potential to screw us badly as it is up to
> the compiler to decide what to do with the parameter here.
>
> Given how many callback and other signatures we have with user_data or
> other unused parameters we end up with 3630 EINA_UNUSED and even 71
> __UNUSED__ in efl alone. All with the potential to be used at some point
> but forgotten to remove the label.
>
> My proposal would be to use -Wno-unused-parameter in our CFLAGS to
> disable this warning and remove all EINA_UNUSED and __UNUSED__ from
> parameters.
>
> I know it has the downside that in the rare case where you add a
> parameter to a signature yourself (read: not using an existing function
> signature) you might add it and forgot to use it. Which will not
> reported as warning in this case.
>
> In my opinion the risk is higher than the benefit here.
>
> I expect people to have a different opinion on this and get really angry
> if I just start to add the CFLAG and remove all EINA_UNSED from
> parameter so I thought I bring it up here to get some opinions. We
> normally have plenty of opinions around. :)
>
> regards
> Stefan Schmidt
>
> --
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--- Hell'O from Yverdoom
Jérémy (jeyzu)
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Migration of Enlightenment GIT Commits Mailing List
On 16/09/13 20:41, Davide Andreoli wrote: > 2013/9/13 Bertrand Jacquin > >> Hi, >> >> This is now done. >> >> List-Id is now git.lists.enlightenment.org. >> >> To subscribe send a mail to git+subscr...@lists.enlightenment.org >> To unsubscribe send a mail to git+unsubscr...@lists.enlightenment.org >> To get help send a mail to : git+h...@lists.enlightenment.org >> >> Archives are still on SF for the moment during import and will be >> available at http://lists.enlightenment.org/git >> >> If anything goes wrong for you (which is very likely for a friday the >> 13th), >> it's time to slap here or by created a phab task in 'Admin' project : >> https://phab.enlightenment.org/project/view/3 >> >> More infos : >> http://www.enlightenment.org/p.php?p=contact&l=en >> https://phab.enlightenment.org/w/hosting/lists/ >> >> Bertrand >> > > SUPER!! The new list seems to work really well, good work man :) > > I have a request for a feature that we lost in the svn/trac => > git/phab/cgit transition: > in the old mails from svn we had a link in the first lines of every commit > that was pointing the > relevant page on track, so that we was able to read the commit in a more > readable form. > It should be cool to have the same feature from git, something like: > Will do. -- Tom. -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ 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/02: Remove __UNUSED__ from function declaration where parameter is actually used.
On 17/09/13 08:30, Stefan Schmidt wrote: > Hello. > > On 09/17/2013 07:44 AM, Chris Michael - Enlightenment Git wrote: >> devilhorns pushed a commit to branch master. >> >> commit 64bc97c53c5c3772595f9d2321f9e19590d8a477 >> Author: Chris Michael >> Date: Mon Sep 16 11:40:30 2013 +0100 >> >> Remove __UNUSED__ from function declaration where parameter is >> actually used. > > This brings an old topic back into my mind. > > Its not the first time we eagerly tagged parameters as unused because > gcc warned about it and later started to use them without removing the > unused label. This has the potential to screw us badly as it is up to > the compiler to decide what to do with the parameter here. I don't know much about the exact implementation details of GCC, but I find it very unlikely that GCC is allowed, or will ever actually do anything about a *used* variable that is marked as unused. That just sounds too crazy to be true. So I don't think we'll ever get screwed. > > Given how many callback and other signatures we have with user_data or > other unused parameters we end up with 3630 EINA_UNUSED and even 71 > __UNUSED__ in efl alone. All with the potential to be used at some point > but forgotten to remove the label. Again, not really an issue. > > My proposal would be to use -Wno-unused-parameter in our CFLAGS to > disable this warning and remove all EINA_UNUSED and __UNUSED__ from > parameters. > > I know it has the downside that in the rare case where you add a > parameter to a signature yourself (read: not using an existing function > signature) you might add it and forgot to use it. Which will not > reported as warning in this case. > > In my opinion the risk is higher than the benefit here. I disagree. I find this warning very useful when prototyping and refactoring APIs (both internal and external). I would really hate losing that in a mess of warnings. > > I expect people to have a different opinion on this and get really angry > if I just start to add the CFLAG and remove all EINA_UNSED from > parameter so I thought I bring it up here to get some opinions. We > normally have plenty of opinions around. :) I would definitely be angry. Not because I disagree with the whole motion, but because it's one of those things that should be discussed (so good job discussing). We are already quite good with that. We used to be a bit better a while back, unfortunately some people introduced new warnings. However, we are still good. I think it's well worth to maintain this. -- Tom. -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ 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/02: Remove __UNUSED__ from function declaration where parameter is actually used.
On 17/09/13 10:21, Tom Hacohen wrote: > On 17/09/13 08:30, Stefan Schmidt wrote: >> Hello. >> >> On 09/17/2013 07:44 AM, Chris Michael - Enlightenment Git wrote: >>> devilhorns pushed a commit to branch master. >>> >>> commit 64bc97c53c5c3772595f9d2321f9e19590d8a477 >>> Author: Chris Michael >>> Date: Mon Sep 16 11:40:30 2013 +0100 >>> >>>Remove __UNUSED__ from function declaration where parameter is >>>actually used. >> >> This brings an old topic back into my mind. >> >> Its not the first time we eagerly tagged parameters as unused because >> gcc warned about it and later started to use them without removing the >> unused label. This has the potential to screw us badly as it is up to >> the compiler to decide what to do with the parameter here. > > I don't know much about the exact implementation details of GCC, but I > find it very unlikely that GCC is allowed, or will ever actually do > anything about a *used* variable that is marked as unused. That just > sounds too crazy to be true. So I don't think we'll ever get screwed. > >> >> Given how many callback and other signatures we have with user_data or >> other unused parameters we end up with 3630 EINA_UNUSED and even 71 >> __UNUSED__ in efl alone. All with the potential to be used at some point >> but forgotten to remove the label. > > Again, not really an issue. >> >> My proposal would be to use -Wno-unused-parameter in our CFLAGS to >> disable this warning and remove all EINA_UNUSED and __UNUSED__ from >> parameters. >> >> I know it has the downside that in the rare case where you add a >> parameter to a signature yourself (read: not using an existing function >> signature) you might add it and forgot to use it. Which will not >> reported as warning in this case. >> >> In my opinion the risk is higher than the benefit here. > > I disagree. I find this warning very useful when prototyping and > refactoring APIs (both internal and external). I would really hate > losing that in a mess of warnings. >> >> I expect people to have a different opinion on this and get really angry >> if I just start to add the CFLAG and remove all EINA_UNSED from >> parameter so I thought I bring it up here to get some opinions. We >> normally have plenty of opinions around. :) > > I would definitely be angry. Not because I disagree with the whole > motion, but because it's one of those things that should be discussed > (so good job discussing). > > > We are already quite good with that. We used to be a bit better a while > back, unfortunately some people introduced new warnings. However, we are > still good. I think it's well worth to maintain this. OK, just checked the gcc manual: http://gcc.gnu.org/onlinedocs/gcc-3.1/gcc/Variable-Attributes.html unused This attribute, attached to a variable, means that the variable is meant to be possibly unused. GCC will not produce a warning for this variable. It's OK to use it even for variables that are used. -- Tom. -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ 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/02: Remove __UNUSED__ from function declaration where parameter is actually used.
On Tue, 17 Sep 2013 10:21:35 +0100 Tom Hacohen wrote: > On 17/09/13 08:30, Stefan Schmidt wrote: > > Hello. > > > > On 09/17/2013 07:44 AM, Chris Michael - Enlightenment Git wrote: > >> devilhorns pushed a commit to branch master. > >> > >> commit 64bc97c53c5c3772595f9d2321f9e19590d8a477 > >> Author: Chris Michael > >> Date: Mon Sep 16 11:40:30 2013 +0100 > >> > >> Remove __UNUSED__ from function declaration where parameter > >> is actually used. > > > > This brings an old topic back into my mind. > > > > Its not the first time we eagerly tagged parameters as unused > > because gcc warned about it and later started to use them without > > removing the unused label. This has the potential to screw us badly > > as it is up to the compiler to decide what to do with the parameter > > here. > > I don't know much about the exact implementation details of GCC, but > I find it very unlikely that GCC is allowed, or will ever actually do > anything about a *used* variable that is marked as unused. That just > sounds too crazy to be true. So I don't think we'll ever get screwed. Lots of things gcc does are too crazy to be true. Just ask Rob Landley to get an ear full. -- 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 -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk___ 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/02: Remove __UNUSED__ from function declaration where parameter is actually used.
Hello. As you like to point out problems with mails. No need to CC me, I'm on the list. :) I also know that thunderbird sucks at this but I'm able to do it. :) On 09/17/2013 10:21 AM, Tom Hacohen wrote: > On 17/09/13 08:30, Stefan Schmidt wrote: >> Hello. >> >> On 09/17/2013 07:44 AM, Chris Michael - Enlightenment Git wrote: >>> devilhorns pushed a commit to branch master. >>> >>> commit 64bc97c53c5c3772595f9d2321f9e19590d8a477 >>> Author: Chris Michael >>> Date: Mon Sep 16 11:40:30 2013 +0100 >>> >>> Remove __UNUSED__ from function declaration where parameter is >>> actually used. >> >> This brings an old topic back into my mind. >> >> Its not the first time we eagerly tagged parameters as unused because >> gcc warned about it and later started to use them without removing the >> unused label. This has the potential to screw us badly as it is up to >> the compiler to decide what to do with the parameter here. > > I don't know much about the exact implementation details of GCC, but I > find it very unlikely that GCC is allowed, or will ever actually do > anything about a *used* variable that is marked as unused. That just > sounds too crazy to be true. So I don't think we'll ever get screwed. I have in the back of my mind that we already screwed by this. I don't have the details at hand so I can't proof it. If I ever run into this problem with efl I will bill you the number of hours I had to work it out. Could easily be days for such a thing. :) >> >> Given how many callback and other signatures we have with user_data or >> other unused parameters we end up with 3630 EINA_UNUSED and even 71 >> __UNUSED__ in efl alone. All with the potential to be used at some point >> but forgotten to remove the label. > > Again, not really an issue. >> >> My proposal would be to use -Wno-unused-parameter in our CFLAGS to >> disable this warning and remove all EINA_UNUSED and __UNUSED__ from >> parameters. >> >> I know it has the downside that in the rare case where you add a >> parameter to a signature yourself (read: not using an existing function >> signature) you might add it and forgot to use it. Which will not >> reported as warning in this case. >> >> In my opinion the risk is higher than the benefit here. > > I disagree. I find this warning very useful when prototyping and > refactoring APIs (both internal and external). I would really hate > losing that in a mess of warnings. You just nominated yourself for fixing warnings to not have a mess of them. Congrats. :) >> I expect people to have a different opinion on this and get really angry >> if I just start to add the CFLAG and remove all EINA_UNSED from >> parameter so I thought I bring it up here to get some opinions. We >> normally have plenty of opinions around. :) > > I would definitely be angry. Not because I disagree with the whole > motion, but because it's one of those things that should be discussed > (so good job discussing). > > > We are already quite good with that. We used to be a bit better a while > back, unfortunately some people introduced new warnings. However, we are > still good. I think it's well worth to maintain this. As written above you won the job taking an eye on this. :) I will put this into the shelve with things I gave up on for EFL. Sitting next to a review-and-pull workflow, good commit messages and a sane coding style. regards Stefan Schmidt -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Migration of Enlightenment GIT Commits Mailing List
On 17/09/13 10:08, Tom Hacohen wrote: > On 16/09/13 20:41, Davide Andreoli wrote: >> 2013/9/13 Bertrand Jacquin >> >>> Hi, >>> >>> This is now done. >>> >>> List-Id is now git.lists.enlightenment.org. >>> >>> To subscribe send a mail to git+subscr...@lists.enlightenment.org >>> To unsubscribe send a mail to git+unsubscr...@lists.enlightenment.org >>> To get help send a mail to : git+h...@lists.enlightenment.org >>> >>> Archives are still on SF for the moment during import and will be >>> available at http://lists.enlightenment.org/git >>> >>> If anything goes wrong for you (which is very likely for a friday the >>> 13th), >>> it's time to slap here or by created a phab task in 'Admin' project : >>> https://phab.enlightenment.org/project/view/3 >>> >>> More infos : >>> http://www.enlightenment.org/p.php?p=contact&l=en >>> https://phab.enlightenment.org/w/hosting/lists/ >>> >>> Bertrand >>> >> >> SUPER!! The new list seems to work really well, good work man :) >> >> I have a request for a feature that we lost in the svn/trac => >> git/phab/cgit transition: >>in the old mails from svn we had a link in the first lines of every commit >> that was pointing the >> relevant page on track, so that we was able to read the commit in a more >> readable form. >> It should be cool to have the same feature from git, something like: >> > > > Will do. Done. I only put a link to git.e.org, not phab as it's too hard/impossible to guess the tag people choose for repos on phab, at least automatically. -- Tom. -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ 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/02: Remove __UNUSED__ from function declaration where parameter is actually used.
On 17/09/13 10:40, Stefan Schmidt wrote: > Hello. > > As you like to point out problems with mails. No need to CC me, I'm on > the list. :) > > I also know that thunderbird sucks at this but I'm able to do it. :) I actually do it on purpose. By default thunderbird replies to list, I have to explicitly choose reply to all. I do that because that's how I'd like to be treated as well. I'm replying to you in specific with everyone to hear, hence you are in the "To" and everyone is in "cc". It has the additional bonus, that for most people it gets to their inbox instead of the ML dir, which is as expected (in my pov) when replying directly. > > On 09/17/2013 10:21 AM, Tom Hacohen wrote: >> On 17/09/13 08:30, Stefan Schmidt wrote: >>> Hello. >>> >>> On 09/17/2013 07:44 AM, Chris Michael - Enlightenment Git wrote: devilhorns pushed a commit to branch master. commit 64bc97c53c5c3772595f9d2321f9e19590d8a477 Author: Chris Michael Date: Mon Sep 16 11:40:30 2013 +0100 Remove __UNUSED__ from function declaration where parameter is actually used. >>> >>> This brings an old topic back into my mind. >>> >>> Its not the first time we eagerly tagged parameters as unused because >>> gcc warned about it and later started to use them without removing the >>> unused label. This has the potential to screw us badly as it is up to >>> the compiler to decide what to do with the parameter here. >> >> I don't know much about the exact implementation details of GCC, but I >> find it very unlikely that GCC is allowed, or will ever actually do >> anything about a *used* variable that is marked as unused. That just >> sounds too crazy to be true. So I don't think we'll ever get screwed. > > I have in the back of my mind that we already screwed by this. I don't > have the details at hand so I can't proof it. > > If I ever run into this problem with efl I will bill you the number of > hours I had to work it out. Could easily be days for such a thing. :) Well, both common-sense (according to David that might not apply to gcc), and the gcc manual are on my side on this one. > >>> >>> Given how many callback and other signatures we have with user_data or >>> other unused parameters we end up with 3630 EINA_UNUSED and even 71 >>> __UNUSED__ in efl alone. All with the potential to be used at some point >>> but forgotten to remove the label. >> >> Again, not really an issue. >>> >>> My proposal would be to use -Wno-unused-parameter in our CFLAGS to >>> disable this warning and remove all EINA_UNUSED and __UNUSED__ from >>> parameters. >>> >>> I know it has the downside that in the rare case where you add a >>> parameter to a signature yourself (read: not using an existing function >>> signature) you might add it and forgot to use it. Which will not >>> reported as warning in this case. >>> >>> In my opinion the risk is higher than the benefit here. >> >> I disagree. I find this warning very useful when prototyping and >> refactoring APIs (both internal and external). I would really hate >> losing that in a mess of warnings. > > You just nominated yourself for fixing warnings to not have a mess of > them. Congrats. :) I used to do it a lot, and I'll do it still if I find anything obvious. The problem is, I don't want to silence warnings, I want warnings to be fixed. Usually, that means spending a lot of time on code you are not familiar with (e.g the Evas_GL code). > >>> I expect people to have a different opinion on this and get really angry >>> if I just start to add the CFLAG and remove all EINA_UNSED from >>> parameter so I thought I bring it up here to get some opinions. We >>> normally have plenty of opinions around. :) >> >> I would definitely be angry. Not because I disagree with the whole >> motion, but because it's one of those things that should be discussed >> (so good job discussing). >> >> >> We are already quite good with that. We used to be a bit better a while >> back, unfortunately some people introduced new warnings. However, we are >> still good. I think it's well worth to maintain this. > > As written above you won the job taking an eye on this. :) That's hardly an argument for or against anything. > > I will put this into the shelve with things I gave up on for EFL. > Sitting next to a review-and-pull workflow, good commit messages and a > sane coding style. I think you are meant to lock such things in the drawer, like laptops, cellphones, your mouse and your desktop's hard-drive. -- Tom. -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk _
Re: [E-devel] New emails for every b0rker
On 2013-09-17 08:35, Guillaume Friloux wrote: > On 16/09/2013 19:51, Bertrand Jacquin wrote: >> Ladies, >> >> Everyone of you having commit access, also seems to be called >> developers does now have an email @enlightenment.org. >> >> Emails send to a developer is then forwarded to emails you have >> declared >> in the E-Mail: info.txt pattern. >> >> Only valid email are processed (meaning not starting with a dash >> (minus >> ?)), one or more is accepted. So be carefull about what email you have >> registered (isn't it dan ;). Change in that file is learn every 15 >> minutes. >> >> So this work for domain enlightenment.org, efl.so and libefl.so >> >> Your dear spam source, >> Report every issue and claims here or in the phab Admin project. >> > Hello, > I can't make it to work. > Tried sending mails to k...@enlightenment.org, k...@efl.so and > k...@libefl.so without success. What I can see it that guillaume.fril...@gmail.com send a mail to k...@enlightenment.org yesterday at 19:00 UTC (21:00 CEST) with subject "Test", that email have been forwarded back to guillaume.fril...@gmail.com. From guillaume.fril...@gmail.com to k...@efl.so at 21:00 CEST forwarded to guillaume.fril...@gmail.com. From guillaume.fril...@gmail.com to k...@libefl.so at 21:00 CEST forwarded to guillaume.fril...@gmail.com. Maybe your gmail drop/mask same mail in your inbox ? -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] New emails for every b0rker
On 17/09/13 11:03, Bertrand Jacquin wrote: > On 2013-09-17 08:35, Guillaume Friloux wrote: >> On 16/09/2013 19:51, Bertrand Jacquin wrote: >>> Ladies, >>> >>> Everyone of you having commit access, also seems to be called >>> developers does now have an email @enlightenment.org. >>> >>> Emails send to a developer is then forwarded to emails you have >>> declared >>> in the E-Mail: info.txt pattern. >>> >>> Only valid email are processed (meaning not starting with a dash >>> (minus >>> ?)), one or more is accepted. So be carefull about what email you have >>> registered (isn't it dan ;). Change in that file is learn every 15 >>> minutes. >>> >>> So this work for domain enlightenment.org, efl.so and libefl.so >>> >>> Your dear spam source, >>> Report every issue and claims here or in the phab Admin project. >>> >> Hello, >> I can't make it to work. >> Tried sending mails to k...@enlightenment.org, k...@efl.so and >> k...@libefl.so without success. > > What I can see it that guillaume.fril...@gmail.com send a mail to > k...@enlightenment.org yesterday at 19:00 UTC (21:00 CEST) with subject > "Test", that email have been forwarded back to > guillaume.fril...@gmail.com. > > From guillaume.fril...@gmail.com to k...@efl.so at 21:00 CEST forwarded > to guillaume.fril...@gmail.com. > From guillaume.fril...@gmail.com to k...@libefl.so at 21:00 CEST > forwarded to guillaume.fril...@gmail.com. > > Maybe your gmail drop/mask same mail in your inbox ? > Yeah, was about to say. From my experiences with stosb.com, it doesn't really work from the same email. Google doesn't mark it as a new email, and you don't see it in your inbox. Really annoying. I will send you an email now. -- Tom. -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ 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/02: Remove __UNUSED__ from function declaration where parameter is actually used.
On Tue, 17 Sep 2013 10:54:43 +0100 Tom Hacohen wrote: > On 17/09/13 10:40, Stefan Schmidt wrote: > > Hello. > > > > As you like to point out problems with mails. No need to CC me, I'm > > on the list. :) > > > > I also know that thunderbird sucks at this but I'm able to do it. :) > > I actually do it on purpose. By default thunderbird replies to list, > I have to explicitly choose reply to all. I do that because that's > how I'd like to be treated as well. I'm replying to you in specific > with everyone to hear, hence you are in the "To" and everyone is in > "cc". > > It has the additional bonus, that for most people it gets to their > inbox instead of the ML dir, which is as expected (in my pov) when > replying directly. Then there is the opposing side that does not want to be CCed, and has said so. This is how we like to be treated. Not to mention the people that CC the likes of us just to annoy us. This is why I have filter rules to make sure mailing list emails actually end up on the mailing list, where they belong, with no duplicates. Makes it easier to find stuff if parts of the mailing list are not scattered elsewhere. People have to get through a white list to get to my inbox, mailing list stuff goes to the lists folders, otherwise it goes to spam. No one on this mailing list is on my white list. :-P -- 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 -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk___ 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/02: Remove __UNUSED__ from function declaration where parameter is actually used.
On 09/17/2013 10:54 AM, Tom Hacohen wrote: > On 17/09/13 10:40, Stefan Schmidt wrote: >> Hello. >> >> As you like to point out problems with mails. No need to CC me, I'm on >> the list. :) >> >> I also know that thunderbird sucks at this but I'm able to do it. :) > > I actually do it on purpose. By default thunderbird replies to list, I Not mine. > have to explicitly choose reply to all. I do that because that's how I'd > like to be treated as well. I'm replying to you in specific with > everyone to hear, hence you are in the "To" and everyone is in "cc". Well, not everyone would like to be treated like you. :) > It has the additional bonus, that for most people it gets to their inbox > instead of the ML dir, which is as expected (in my pov) when replying > directly. Not happening here. >> >> On 09/17/2013 10:21 AM, Tom Hacohen wrote: >>> On 17/09/13 08:30, Stefan Schmidt wrote: Hello. On 09/17/2013 07:44 AM, Chris Michael - Enlightenment Git wrote: > devilhorns pushed a commit to branch master. > > commit 64bc97c53c5c3772595f9d2321f9e19590d8a477 > Author: Chris Michael > Date: Mon Sep 16 11:40:30 2013 +0100 > >Remove __UNUSED__ from function declaration where parameter is >actually used. This brings an old topic back into my mind. Its not the first time we eagerly tagged parameters as unused because gcc warned about it and later started to use them without removing the unused label. This has the potential to screw us badly as it is up to the compiler to decide what to do with the parameter here. >>> >>> I don't know much about the exact implementation details of GCC, but I >>> find it very unlikely that GCC is allowed, or will ever actually do >>> anything about a *used* variable that is marked as unused. That just >>> sounds too crazy to be true. So I don't think we'll ever get screwed. >> >> I have in the back of my mind that we already screwed by this. I don't >> have the details at hand so I can't proof it. >> >> If I ever run into this problem with efl I will bill you the number of >> hours I had to work it out. Could easily be days for such a thing. :) > > Well, both common-sense (according to David that might not apply to > gcc), and the gcc manual are on my side on this one. Stay on your side. Given how many callback and other signatures we have with user_data or other unused parameters we end up with 3630 EINA_UNUSED and even 71 __UNUSED__ in efl alone. All with the potential to be used at some > point but forgotten to remove the label. >>> >>> Again, not really an issue. My proposal would be to use -Wno-unused-parameter in our CFLAGS to disable this warning and remove all EINA_UNUSED and __UNUSED__ from parameters. I know it has the downside that in the rare case where you add a parameter to a signature yourself (read: not using an existing > function signature) you might add it and forgot to use it. Which will not reported as warning in this case. In my opinion the risk is higher than the benefit here. >>> >>> I disagree. I find this warning very useful when prototyping and >>> refactoring APIs (both internal and external). I would really hate >>> losing that in a mess of warnings. >> >> You just nominated yourself for fixing warnings to not have a mess of >> them. Congrats. :) > > I used to do it a lot, and I'll do it still if I find anything obvious. > The problem is, I don't want to silence warnings, I want warnings to be > fixed. Usually, that means spending a lot of time on code you are not > familiar with (e.g the Evas_GL code). Thanks. I know that. I digged through code I never wanted to see to make a correct fix. I expect people to have a different opinion on this and get really > angry if I just start to add the CFLAG and remove all EINA_UNSED from parameter so I thought I bring it up here to get some opinions. We normally have plenty of opinions around. :) >>> >>> I would definitely be angry. Not because I disagree with the whole >>> motion, but because it's one of those things that should be discussed >>> (so good job discussing). >>> >>> >>> We are already quite good with that. We used to be a bit better a while >>> back, unfortunately some people introduced new warnings. However, we > are >>> still good. I think it's well worth to maintain this. >> >> As written above you won the job taking an eye on this. :) > > That's hardly an argument for or against anything. What makes you think this is an argument? It is a statement I made without arguing about the original problem anymore. You stated you want to see them and I feel we see but don't fix them so you have won the job doing it in my eyes. >> I will put this into the shelve with things I gave up on for EFL. >> Sitting next to a review-and-pull workflow, good commit messages and a >> sane coding style. > > I think
Re: [E-devel] New emails for every b0rker
I had the same problem, but you're right. It works when sending with another email address... Thx! -- Raoul Hecky 2013/9/17 Bertrand Jacquin > On 2013-09-17 08:35, Guillaume Friloux wrote: > > On 16/09/2013 19:51, Bertrand Jacquin wrote: > >> Ladies, > >> > >> Everyone of you having commit access, also seems to be called > >> developers does now have an email @enlightenment.org. > >> > >> Emails send to a developer is then forwarded to emails you have > >> declared > >> in the E-Mail: info.txt pattern. > >> > >> Only valid email are processed (meaning not starting with a dash > >> (minus > >> ?)), one or more is accepted. So be carefull about what email you have > >> registered (isn't it dan ;). Change in that file is learn every 15 > >> minutes. > >> > >> So this work for domain enlightenment.org, efl.so and libefl.so > >> > >> Your dear spam source, > >> Report every issue and claims here or in the phab Admin project. > >> > > Hello, > > I can't make it to work. > > Tried sending mails to k...@enlightenment.org, k...@efl.so and > > k...@libefl.so without success. > > What I can see it that guillaume.fril...@gmail.com send a mail to > k...@enlightenment.org yesterday at 19:00 UTC (21:00 CEST) with subject > "Test", that email have been forwarded back to > guillaume.fril...@gmail.com. > > From guillaume.fril...@gmail.com to k...@efl.so at 21:00 CEST forwarded > to guillaume.fril...@gmail.com. > From guillaume.fril...@gmail.com to k...@libefl.so at 21:00 CEST > forwarded to guillaume.fril...@gmail.com. > > Maybe your gmail drop/mask same mail in your inbox ? > > > -- > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, > SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack > includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ 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/02: Remove __UNUSED__ from function declaration where parameter is actually used.
On 17/09/13 11:10, David Seikel wrote: > On Tue, 17 Sep 2013 10:54:43 +0100 Tom Hacohen > wrote: > >> On 17/09/13 10:40, Stefan Schmidt wrote: >>> Hello. >>> >>> As you like to point out problems with mails. No need to CC me, I'm >>> on the list. :) >>> >>> I also know that thunderbird sucks at this but I'm able to do it. :) >> >> I actually do it on purpose. By default thunderbird replies to list, >> I have to explicitly choose reply to all. I do that because that's >> how I'd like to be treated as well. I'm replying to you in specific >> with everyone to hear, hence you are in the "To" and everyone is in >> "cc". >> >> It has the additional bonus, that for most people it gets to their >> inbox instead of the ML dir, which is as expected (in my pov) when >> replying directly. > > Then there is the opposing side that does not want to be CCed, and has > said so. This is how we like to be treated. Not to mention the people > that CC the likes of us just to annoy us. This is why I have filter > rules to make sure mailing list emails actually end up on the mailing > list, where they belong, with no duplicates. Makes it easier to find > stuff if parts of the mailing list are not scattered elsewhere. > > People have to get through a white list to get to my inbox, mailing > list stuff goes to the lists folders, otherwise it goes to spam. No one > on this mailing list is on my white list. :-P Huh? I understood from Mike that you'd like to be CCed to all the emails in the world. Maybe I got him wrong. :) Anyhow, I didn't know you didn't like to be CCed, but as I said, it's how email works, you put whoever you are talking to in the "To" field, and whoever you'd like to read it as well in the "CC" field... Anyhow, I will try my best not to CC you and Stefan. -- Tom. -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ 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/02: Remove __UNUSED__ from function declaration where parameter is actually used.
On 17/09/13 11:15, Stefan Schmidt wrote: > On 09/17/2013 10:54 AM, Tom Hacohen wrote: >> On 17/09/13 10:40, Stefan Schmidt wrote: >>> Hello. >>> >>> As you like to point out problems with mails. No need to CC me, I'm on >>> the list. :) >>> >>> I also know that thunderbird sucks at this but I'm able to do it. :) >> >> I actually do it on purpose. By default thunderbird replies to list, I > > Not mine. How do I get it to work like yours? :) > >> have to explicitly choose reply to all. I do that because that's how I'd >> like to be treated as well. I'm replying to you in specific with >> everyone to hear, hence you are in the "To" and everyone is in "cc". > > Well, not everyone would like to be treated like you. :) Yeah sure, but by default I assume people would like to treated the same. I think it's a better default than assuming people would like to be treated differently. > >> It has the additional bonus, that for most people it gets to their inbox >> instead of the ML dir, which is as expected (in my pov) when replying >> directly. > > Not happening here. How did you write your Thunderbird rules? I just filter according to list-id which is not there if sent directly. > >>> >>> On 09/17/2013 10:21 AM, Tom Hacohen wrote: On 17/09/13 08:30, Stefan Schmidt wrote: > Hello. > > On 09/17/2013 07:44 AM, Chris Michael - Enlightenment Git wrote: >> devilhorns pushed a commit to branch master. >> >> commit 64bc97c53c5c3772595f9d2321f9e19590d8a477 >> Author: Chris Michael >> Date: Mon Sep 16 11:40:30 2013 +0100 >> >> Remove __UNUSED__ from function declaration where parameter is >> actually used. > > This brings an old topic back into my mind. > > Its not the first time we eagerly tagged parameters as unused because > gcc warned about it and later started to use them without removing the > unused label. This has the potential to screw us badly as it is up to > the compiler to decide what to do with the parameter here. I don't know much about the exact implementation details of GCC, but I find it very unlikely that GCC is allowed, or will ever actually do anything about a *used* variable that is marked as unused. That just sounds too crazy to be true. So I don't think we'll ever get screwed. >>> >>> I have in the back of my mind that we already screwed by this. I don't >>> have the details at hand so I can't proof it. >>> >>> If I ever run into this problem with efl I will bill you the number of >>> hours I had to work it out. Could easily be days for such a thing. :) >> >> Well, both common-sense (according to David that might not apply to >> gcc), and the gcc manual are on my side on this one. > > Stay on your side. > > Given how many callback and other signatures we have with user_data or > other unused parameters we end up with 3630 EINA_UNUSED and even 71 > __UNUSED__ in efl alone. All with the potential to be used at some >> point > but forgotten to remove the label. Again, not really an issue. > > My proposal would be to use -Wno-unused-parameter in our CFLAGS to > disable this warning and remove all EINA_UNUSED and __UNUSED__ from > parameters. > > I know it has the downside that in the rare case where you add a > parameter to a signature yourself (read: not using an existing >> function > signature) you might add it and forgot to use it. Which will not > reported as warning in this case. > > In my opinion the risk is higher than the benefit here. I disagree. I find this warning very useful when prototyping and refactoring APIs (both internal and external). I would really hate losing that in a mess of warnings. >>> >>> You just nominated yourself for fixing warnings to not have a mess of >>> them. Congrats. :) >> >> I used to do it a lot, and I'll do it still if I find anything obvious. >> The problem is, I don't want to silence warnings, I want warnings to be >> fixed. Usually, that means spending a lot of time on code you are not >> familiar with (e.g the Evas_GL code). > > Thanks. I know that. I digged through code I never wanted to see to make > a correct fix. I know you know, I just wanted it to be written down in protocol. > > I expect people to have a different opinion on this and get really >> angry > if I just start to add the CFLAG and remove all EINA_UNSED from > parameter so I thought I bring it up here to get some opinions. We > normally have plenty of opinions around. :) I would definitely be angry. Not because I disagree with the whole motion, but because it's one of those things that should be discussed (so good job discussing). We are already quite good with that. We used to be a bit better a while back, unfortunately some people introduced new warnings. However, we >> are still good. I think it's well worth to maint
[E-devel] Debian packaging files
Hi all, I'm looking for the debian packaging files (debian/rules, debian/control, etc) used on the https://launchpad.net/~efl ppa. Does anyone know where are they? Regards -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] New emails for every b0rker
On 17/09/2013 12:03, Bertrand Jacquin wrote: What I can see it that guillaume.fril...@gmail.com send a mail to k...@enlightenment.org yesterday at 19:00 UTC (21:00 CEST) with subject "Test", that email have been forwarded back to guillaume.fril...@gmail.com. From guillaume.fril...@gmail.com to k...@efl.so at 21:00 CEST forwarded to guillaume.fril...@gmail.com. From guillaume.fril...@gmail.com to k...@libefl.so at 21:00 CEST forwarded to guillaume.fril...@gmail.com. Maybe your gmail drop/mask same mail in your inbox ? I dont have access to my personnal mail account from here, but it seems to be that. Thx for help =) <>-- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/elementary] master 01/01: elm headers: fixed documentation about elm_object_item supports.
seoz pushed a commit to branch master. http://git.enlightenment.org/core/elementary.git/commit/?id=33d27c1e2ef4dfa00dca5d941d9cbdb652034c91 commit 33d27c1e2ef4dfa00dca5d941d9cbdb652034c91 Author: Daniel Juyung Seo Date: Wed Sep 18 01:56:16 2013 +0900 elm headers: fixed documentation about elm_object_item supports. --- src/lib/elc_ctxpopup.h | 1 + src/lib/elc_hoversel.h | 1 + src/lib/elc_multibuttonentry.h | 1 + src/lib/elc_naviframe.h| 1 + src/lib/elc_popup.h| 6 +++--- src/lib/elm_diskselector.h | 1 + src/lib/elm_flipselector.h | 3 ++- src/lib/elm_gengrid.h | 14 ++ src/lib/elm_genlist.h | 16 src/lib/elm_index.h| 3 +++ src/lib/elm_list.h | 1 + src/lib/elm_menu.h | 1 + src/lib/elm_segment_control.h | 1 + src/lib/elm_slideshow.h| 3 +++ src/lib/elm_toolbar.h | 4 15 files changed, 41 insertions(+), 16 deletions(-) diff --git a/src/lib/elc_ctxpopup.h b/src/lib/elc_ctxpopup.h index c3aa610..b204b7b 100644 --- a/src/lib/elc_ctxpopup.h +++ b/src/lib/elc_ctxpopup.h @@ -46,6 +46,7 @@ * @li @ref elm_object_disabled_get * * Supported elm_object_item common APIs. + * @li @ref elm_object_item_del * @li @ref elm_object_item_disabled_set * @li @ref elm_object_item_disabled_get * @li @ref elm_object_item_part_text_set diff --git a/src/lib/elc_hoversel.h b/src/lib/elc_hoversel.h index f676b97..d085491 100644 --- a/src/lib/elc_hoversel.h +++ b/src/lib/elc_hoversel.h @@ -41,6 +41,7 @@ * @li @ref elm_object_part_content_unset * * Supported elm_object_item common APIs. + * @li elm_object_item_del * @li elm_object_item_part_text_get * * See @ref tutorial_hoversel for an example. diff --git a/src/lib/elc_multibuttonentry.h b/src/lib/elc_multibuttonentry.h index 9653548..73a125d 100644 --- a/src/lib/elc_multibuttonentry.h +++ b/src/lib/elc_multibuttonentry.h @@ -46,6 +46,7 @@ * @li "default" - A label of the multi-button entry item * * Supported elm_object_item common APIs. + * @li @ref elm_object_item_del * @li @ref elm_object_item_part_text_set * @li @ref elm_object_item_part_text_get */ diff --git a/src/lib/elc_naviframe.h b/src/lib/elc_naviframe.h index a2f4af6..1413496 100644 --- a/src/lib/elc_naviframe.h +++ b/src/lib/elc_naviframe.h @@ -63,6 +63,7 @@ * * All the parts, for content and text, described here will also be * reachable by naviframe @b items direct calls: + * @li @ref elm_object_item_del * @li @ref elm_object_item_part_text_set * @li @ref elm_object_item_part_text_get * @li @ref elm_object_item_part_content_set diff --git a/src/lib/elc_popup.h b/src/lib/elc_popup.h index 4a403cd..86b8dcf 100644 --- a/src/lib/elc_popup.h +++ b/src/lib/elc_popup.h @@ -100,14 +100,14 @@ * @li "default" - Item's label * * Supported elm_object_item common APIs. - * @li @ref elm_object_item_disabled_set - * @li @ref elm_object_item_disabled_get * @li @ref elm_object_item_part_text_set * @li @ref elm_object_item_part_text_get * @li @ref elm_object_item_part_content_set * @li @ref elm_object_item_part_content_get - * @li @ref elm_object_item_signal_emit + * @li @ref elm_object_item_disabled_set + * @li @ref elm_object_item_disabled_get * @li @ref elm_object_item_del + * @li @ref elm_object_item_signal_emit * * Here are some sample code to illustrate Popup usage: * @li @ref popup_example_01_c diff --git a/src/lib/elm_diskselector.h b/src/lib/elm_diskselector.h index 50dcf57..6035b8e 100644 --- a/src/lib/elm_diskselector.h +++ b/src/lib/elm_diskselector.h @@ -49,6 +49,7 @@ * @li "default" - Label of the diskselector item * * Supported elm_object_item common APIs. + * @li @ref elm_object_item_del * @li @ref elm_object_item_part_text_set * @li @ref elm_object_item_part_text_get * @li @ref elm_object_item_part_content_set diff --git a/src/lib/elm_flipselector.h b/src/lib/elm_flipselector.h index c1fcdef..1919bb9 100644 --- a/src/lib/elm_flipselector.h +++ b/src/lib/elm_flipselector.h @@ -43,8 +43,9 @@ * @li @ref elm_object_disabled_get * * Supported elm_object_item common APIs. - * @li @ref elm_object_item_text_set + * @li @ref elm_object_item_del * @li @ref elm_object_item_part_text_set + * @li @ref elm_object_item_part_text_get * @li @ref elm_object_item_signal_emit * * Here is an example on its usage: diff --git a/src/lib/elm_gengrid.h b/src/lib/elm_gengrid.h index 1da72a3..e850146 100644 --- a/src/lib/elm_gengrid.h +++ b/src/lib/elm_gengrid.h @@ -242,13 +242,19 @@ * @li elm_object_signal_emit() * * Supported elm_object_item common APIs - * @li elm_object_item_part_content_get() + * @li elm_object_item_part_content_get + * @li elm_object_item_part_text_get + * @li elm_object_item_disabled_set + * @li elm_object_item_disabled_get + * @li elm_object_item_del + * @li elm_object_item_signal_emit + * + * Unsupported elm_object_item common APIs due to the gengr
Re: [E-devel] [EGIT] [core/elementary] master 01/01: elementary: allow custom text part on item list
Well there is no rush on this.
But if you want to support item_part_text_set, how about supporting
item_part_content_set as well?
It looks better for consistency.
Thanks.
Daniel Juyung Seo (SeoZ)
On Tue, Sep 17, 2013 at 5:19 PM, Michaël Bouchaud wrote:
> Sorry, but I don't finish my work to support theme change with customized
> text part.
> I will update changelog and news when I push this work. Surely tonight or
> tomorrow.
>
>
> 2013/9/17 ChunEon Park
>
> > conceptually this is acceptable to me, already all widgets support this
> > kind of customized text set.
> >
> >
> > -Regards, Hermet-
> >
> > -Original Message-
> > From: "Michaël Bouchaud"
> > To: "Enlightenment developer list"<
> > enlightenment-devel@lists.sourceforge.net>;
> > Cc: ;
> > Sent: 2013-09-16 (월) 22:14:56
> > Subject: Re: [E-devel] [EGIT] [core/elementary] master 01/01: elementary:
> > allow custom text part on item list
> >
> > Of course, I can check this. I will try to do it before tonight and fix
> it.
> >
> >
> > 2013/9/16 Daniel Juyung Seo @gmail.com>
> >
> > > Hello Michael Bouchaud,
> > > does this really work?
> > >
> > > It's likely this works only in a very rare cases.
> > > It will be broken in many cases, especially theme change will break
> this.
> > > The label inside the list is managed by elm_list and it'll set the
> label
> > > when the theme is changed.
> > > And so on...
> > >
> > > Can you check this?
> > >
> > > Daniel Juyung Seo (SeoZ)
> > >
> > >
> > > On Mon, Sep 16, 2013 at 7:20 PM, Michaël Bouchaud - Enlightenment Git <
> > > no-re...@enlightenment.org> wrote:
> > >
> > > > yoz pushed a commit to branch master.
> > > >
> > > > commit 5414fdba3c874451b43e0994df897bb3705b1f2d
> > > > Author: Michaël Bouchaud (yoz) @efl.so>
> > > > Date: Mon Sep 16 12:18:24 2013 +0200
> > > >
> > > > elementary: allow custom text part on item list
> > > > ---
> > > > src/lib/elm_list.c 6 +-
> > > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/src/lib/elm_list.c b/src/lib/elm_list.c
> > > > index e193fdf..72d3e9f 100644
> > > > --- a/src/lib/elm_list.c
> > > > +++ b/src/lib/elm_list.c
> > > > @@ -1405,7 +1405,11 @@ _item_text_set_hook(Elm_Object_Item *it,
> > > > {
> > > > Elm_List_Item *list_it = (Elm_List_Item *)it;
> > > >
> > > > - if (part && strcmp(part, "default")) return;
> > > > + if (part && strcmp(part, "default"))
> > > > + {
> > > > +edje_object_part_text_escaped_set(VIEW(list_it), part,
> text);
> > > > +return;
> > > > + }
> > > > if (!eina_stringshare_replace(&list_it->label, text)) return;
> > > > if (VIEW(list_it))
> > > > edje_object_part_text_escaped_set(VIEW(list_it), "elm.text",
> > text);
> > > >
> > > > --
> > > >
> > > >
> > > >
> > >
> > >
> >
> --
> > > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> > > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> > > SharePoint
> > > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> > > includes
> > > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> > >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >
> >
> >
> >
> > --
> > Michaël Bouchaud (yoz) @efl.so>
> >
> >
> --
> > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> > SharePoint
> > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> > includes
> > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> >
> >
> --
> > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> > SharePoint
> > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> > includes
> > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
[EGIT] [core/elementary] master 01/01: [naviframe] Enable item pop during item push.
seoz pushed a commit to branch master.
http://git.enlightenment.org/core/elementary.git/commit/?id=db6be5cba076ff66dc58491972b30506d98f4df3
commit db6be5cba076ff66dc58491972b30506d98f4df3
Author: Jaehyun Cho
Date: Wed Sep 18 02:20:33 2013 +0900
[naviframe] Enable item pop during item push.
Enable item pop during item is pushing (during item push transition).
---
src/lib/elc_naviframe.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/lib/elc_naviframe.c b/src/lib/elc_naviframe.c
index 5347fe8..95aab57 100644
--- a/src/lib/elc_naviframe.c
+++ b/src/lib/elc_naviframe.c
@@ -1663,10 +1663,11 @@ _item_pop(Eo *obj, void *_pd, va_list *list)
it = (Elm_Naviframe_Item *)elm_naviframe_top_item_get(obj);
if (!it) return;
- if (it->animator || it->popping) return;
-
+ if (it->popping) return;
it->popping = EINA_TRUE;
+ ELM_SAFE_FREE(it->animator, ecore_animator_del);
+
if (it->pop_cb)
{
if (!it->pop_cb(it->pop_data, (Elm_Object_Item *)it))
--
Re: [E-devel] Migration of Enlightenment GIT Commits Mailing List
2013/9/17 Tom Hacohen > On 17/09/13 10:08, Tom Hacohen wrote: > > On 16/09/13 20:41, Davide Andreoli wrote: > >> 2013/9/13 Bertrand Jacquin > >> > >>> Hi, > >>> > >>> This is now done. > >>> > >>> List-Id is now git.lists.enlightenment.org. > >>> > >>> To subscribe send a mail to git+subscr...@lists.enlightenment.org > >>> To unsubscribe send a mail to git+unsubscr...@lists.enlightenment.org > >>> To get help send a mail to : git+h...@lists.enlightenment.org > >>> > >>> Archives are still on SF for the moment during import and will be > >>> available at http://lists.enlightenment.org/git > >>> > >>> If anything goes wrong for you (which is very likely for a friday the > >>> 13th), > >>> it's time to slap here or by created a phab task in 'Admin' project : > >>> https://phab.enlightenment.org/project/view/3 > >>> > >>> More infos : > >>> http://www.enlightenment.org/p.php?p=contact&l=en > >>> https://phab.enlightenment.org/w/hosting/lists/ > >>> > >>> Bertrand > >>> > >> > >> SUPER!! The new list seems to work really well, good work man :) > >> > >> I have a request for a feature that we lost in the svn/trac => > >> git/phab/cgit transition: > >>in the old mails from svn we had a link in the first lines of every > commit > >> that was pointing the > >> relevant page on track, so that we was able to read the commit in a more > >> readable form. > >> It should be cool to have the same feature from git, something like: > >> > > > > > > Will do. > > Done. I only put a link to git.e.org, not phab as it's too > hard/impossible to guess the tag people choose for repos on phab, at > least automatically. > Thnks :) > > -- > Tom. > > > > -- > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, > SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack > includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E18 efm bug and ibar question [Correction re EFM]
On 16/09/13 23:07, rob wrote: > I have two installations on my PC with separate /home > One 32 bit with nouveau driver r17100, the other 64bit with nvidia > driver r 17067. The problems affect both installations. > > 1:) Efm cd/dvd drive issue. > > The cd title shows up in the side bar but right-clicking select mount > eventually comes back with > "Can't mount device /dev/sr0 /media cdrom > org.enlightenment,fm2.MountTimeout > Unable to mount the volume with specified time-out" > > It's not a permission issue as I can mount CD in terminology ok. > > With cd mounted via term., return to efm and click cd and the contents > of the cd do not show. A little bit later the mount error message returns. > Settings->Files->Filemanager-> Device are > Mode UDISKS2 > with all 3 checkboxes checked > > Of those options > Mount volumes on insert - doesn't mount > Open filemanager on mount - doesn't start efm > > Tried gdb but nothing shows up. > Turns out it is one of these "invisible" permission issues. Something to do with udisks. Nuked udisks and I can now access the cd drive contents via efm. The error message maybe needs changing. > 2:) Ibar - not sure if this is a feature or not. > > I have 2 shelves each containing only an Ibar > Ibox is not loaded > > Start app from ibar1 and an icon appears at end of ibar2. Same thing the > other way round. Start an app from the menu which is not included in > either ibar and the app icon appears at the end of both ibars. > > > Bye > rob > > > > -- > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] New emails for every b0rker
On Tue, Sep 17, 2013 at 8:03 PM, Lucas De Marchi wrote: > On Mon, Sep 16, 2013 at 2:51 PM, Bertrand Jacquin wrote: >> Ladies, >> >> Everyone of you having commit access, also seems to be called >> developers does now have an email @enlightenment.org. >> >> Emails send to a developer is then forwarded to emails you have declared >> in the E-Mail: info.txt pattern. >> >> Only valid email are processed (meaning not starting with a dash (minus >> ?)), one or more is accepted. So be carefull about what email you have >> registered (isn't it dan ;). Change in that file is learn every 15 minutes. >> >> So this work for domain enlightenment.org, efl.so and libefl.so >> >> Your dear spam source, >> Report every issue and claims here or in the phab Admin project. >> > > Wouldn't it be easier to just send an email to Cedric blaming him when > the build is broken? > And pick a random reason from a list when the build is not broken, but always blame him for something. > Lucas De Marchi > > -- > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ 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: elementary: allow custom text part on item list
Well I am not against but I am worried about some issue related to this
implementation.
To support this correctly, we should maintain all the strings and part
names inside each widget. Actually this is what I asked to Michael Bouchaud.
But this is error-prone.
And actually many of widgets do not support this kind of item text set.
Many widgets do not even have item text set hook and even they have item
text set hook, some of them only accept "default" part.
I hope this will get better but we need to fix many parts.
Thanks.
Daniel Juyung Seo (SeoZ)
On Tue, Sep 17, 2013 at 1:39 PM, ChunEon Park wrote:
> conceptually this is acceptable to me, already all widgets support this
> kind of customized text set.
>
>
> -Regards, Hermet-
>
> -Original Message-
> From: "Michaël Bouchaud"
> To: "Enlightenment developer list"<
> enlightenment-devel@lists.sourceforge.net>;
> Cc: ;
> Sent: 2013-09-16 (월) 22:14:56
> Subject: Re: [E-devel] [EGIT] [core/elementary] master 01/01: elementary:
> allow custom text part on item list
>
> Of course, I can check this. I will try to do it before tonight and fix it.
>
>
> 2013/9/16 Daniel Juyung Seo @gmail.com>
>
> > Hello Michael Bouchaud,
> > does this really work?
> >
> > It's likely this works only in a very rare cases.
> > It will be broken in many cases, especially theme change will break this.
> > The label inside the list is managed by elm_list and it'll set the label
> > when the theme is changed.
> > And so on...
> >
> > Can you check this?
> >
> > Daniel Juyung Seo (SeoZ)
> >
> >
> > On Mon, Sep 16, 2013 at 7:20 PM, Michaël Bouchaud - Enlightenment Git <
> > no-re...@enlightenment.org> wrote:
> >
> > > yoz pushed a commit to branch master.
> > >
> > > commit 5414fdba3c874451b43e0994df897bb3705b1f2d
> > > Author: Michaël Bouchaud (yoz) @efl.so>
> > > Date: Mon Sep 16 12:18:24 2013 +0200
> > >
> > > elementary: allow custom text part on item list
> > > ---
> > > src/lib/elm_list.c 6 +-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/src/lib/elm_list.c b/src/lib/elm_list.c
> > > index e193fdf..72d3e9f 100644
> > > --- a/src/lib/elm_list.c
> > > +++ b/src/lib/elm_list.c
> > > @@ -1405,7 +1405,11 @@ _item_text_set_hook(Elm_Object_Item *it,
> > > {
> > > Elm_List_Item *list_it = (Elm_List_Item *)it;
> > >
> > > - if (part && strcmp(part, "default")) return;
> > > + if (part && strcmp(part, "default"))
> > > + {
> > > +edje_object_part_text_escaped_set(VIEW(list_it), part, text);
> > > +return;
> > > + }
> > > if (!eina_stringshare_replace(&list_it->label, text)) return;
> > > if (VIEW(list_it))
> > > edje_object_part_text_escaped_set(VIEW(list_it), "elm.text",
> text);
> > >
> > > --
> > >
> > >
> > >
> >
> >
> --
> > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> > SharePoint
> > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> > includes
> > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
>
>
> --
> Michaël Bouchaud (yoz) @efl.so>
>
> --
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
> --
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
LIMITED TIME SALE - Full Year o
Re: [E-devel] New emails for every b0rker
This works well for me. Thanks for the good job Daniel Juyung Seo (SeoZ) On Tue, Sep 17, 2013 at 2:51 AM, Bertrand Jacquin wrote: > Ladies, > > Everyone of you having commit access, also seems to be called > developers does now have an email @enlightenment.org. > > Emails send to a developer is then forwarded to emails you have declared > in the E-Mail: info.txt pattern. > > Only valid email are processed (meaning not starting with a dash (minus > ?)), one or more is accepted. So be carefull about what email you have > registered (isn't it dan ;). Change in that file is learn every 15 minutes. > > So this work for domain enlightenment.org, efl.so and libefl.so > > Your dear spam source, > Report every issue and claims here or in the phab Admin project. > > -- > Beber > > > -- > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, > SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack > includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] New emails for every b0rker
On Mon, Sep 16, 2013 at 2:51 PM, Bertrand Jacquin wrote: > Ladies, > > Everyone of you having commit access, also seems to be called > developers does now have an email @enlightenment.org. > > Emails send to a developer is then forwarded to emails you have declared > in the E-Mail: info.txt pattern. > > Only valid email are processed (meaning not starting with a dash (minus > ?)), one or more is accepted. So be carefull about what email you have > registered (isn't it dan ;). Change in that file is learn every 15 minutes. > > So this work for domain enlightenment.org, efl.so and libefl.so > > Your dear spam source, > Report every issue and claims here or in the phab Admin project. > Wouldn't it be easier to just send an email to Cedric blaming him when the build is broken? Lucas De Marchi -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ 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/02: Remove __UNUSED__ from function declaration where parameter is actually used.
On Tue, Sep 17, 2013 at 4:30 AM, Stefan Schmidt wrote: > Hello. > > On 09/17/2013 07:44 AM, Chris Michael - Enlightenment Git wrote: >> devilhorns pushed a commit to branch master. >> >> commit 64bc97c53c5c3772595f9d2321f9e19590d8a477 >> Author: Chris Michael >> Date: Mon Sep 16 11:40:30 2013 +0100 >> >> Remove __UNUSED__ from function declaration where parameter is >> actually used. > > This brings an old topic back into my mind. > > Its not the first time we eagerly tagged parameters as unused because > gcc warned about it and later started to use them without removing the > unused label. This has the potential to screw us badly as it is up to > the compiler to decide what to do with the parameter here. > > Given how many callback and other signatures we have with user_data or > other unused parameters we end up with 3630 EINA_UNUSED and even 71 > __UNUSED__ in efl alone. All with the potential to be used at some point > but forgotten to remove the label. > > My proposal would be to use -Wno-unused-parameter in our CFLAGS to > disable this warning and remove all EINA_UNUSED and __UNUSED__ from > parameters. +1 We use callbacks a lot. And often enough we don't use one parameter or another. Having to *silence* the compiler on every single place about a stupid warning is useless. I'm all in favor or silence it in the build directly. > > I know it has the downside that in the rare case where you add a > parameter to a signature yourself (read: not using an existing function > signature) you might add it and forgot to use it. Which will not > reported as warning in this case. eldbus was made entirely passing -Wno-unused-parameter in CFLAGS. When merging to EFL and forced to drop the flag, I proved my point: there no one single place in which the warning would point to an error. Most of the projects I'm involved with are for long disabling this warning. Lucas De Marchi -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ 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/02: Remove __UNUSED__ from function declaration where parameter is actually used.
On Tue, Sep 17, 2013 at 6:21 AM, Tom Hacohen wrote: > On 17/09/13 08:30, Stefan Schmidt wrote: >> Hello. >> >> On 09/17/2013 07:44 AM, Chris Michael - Enlightenment Git wrote: >>> devilhorns pushed a commit to branch master. >>> >>> commit 64bc97c53c5c3772595f9d2321f9e19590d8a477 >>> Author: Chris Michael >>> Date: Mon Sep 16 11:40:30 2013 +0100 >>> >>> Remove __UNUSED__ from function declaration where parameter is >>> actually used. >> >> This brings an old topic back into my mind. >> >> Its not the first time we eagerly tagged parameters as unused because >> gcc warned about it and later started to use them without removing the >> unused label. This has the potential to screw us badly as it is up to >> the compiler to decide what to do with the parameter here. > > I don't know much about the exact implementation details of GCC, but I > find it very unlikely that GCC is allowed, or will ever actually do > anything about a *used* variable that is marked as unused. That just > sounds too crazy to be true. So I don't think we'll ever get screwed. It won't produce incorrect code. > >> >> Given how many callback and other signatures we have with user_data or >> other unused parameters we end up with 3630 EINA_UNUSED and even 71 >> __UNUSED__ in efl alone. All with the potential to be used at some point >> but forgotten to remove the label. > > Again, not really an issue. >> >> My proposal would be to use -Wno-unused-parameter in our CFLAGS to >> disable this warning and remove all EINA_UNUSED and __UNUSED__ from >> parameters. >> >> I know it has the downside that in the rare case where you add a >> parameter to a signature yourself (read: not using an existing function >> signature) you might add it and forgot to use it. Which will not >> reported as warning in this case. >> >> In my opinion the risk is higher than the benefit here. > > I disagree. I find this warning very useful when prototyping and > refactoring APIs (both internal and external). I would really hate > losing that in a mess of warnings. Then you turn it on once, for that part of the code. Having it as the default isn't helping, but instead requiring more work from others. Lucas De Marchi -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ 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/02: Remove __UNUSED__ from function declaration where parameter is actually used.
On Tue, Sep 17, 2013 at 6:40 AM, Stefan Schmidt wrote: > Hello. > > As you like to point out problems with mails. No need to CC me, I'm on > the list. :) > > I also know that thunderbird sucks at this but I'm able to do it. :) > > On 09/17/2013 10:21 AM, Tom Hacohen wrote: >> On 17/09/13 08:30, Stefan Schmidt wrote: >>> Hello. >>> >>> On 09/17/2013 07:44 AM, Chris Michael - Enlightenment Git wrote: devilhorns pushed a commit to branch master. commit 64bc97c53c5c3772595f9d2321f9e19590d8a477 Author: Chris Michael Date: Mon Sep 16 11:40:30 2013 +0100 Remove __UNUSED__ from function declaration where parameter is actually used. >>> >>> This brings an old topic back into my mind. >>> >>> Its not the first time we eagerly tagged parameters as unused because >>> gcc warned about it and later started to use them without removing the >>> unused label. This has the potential to screw us badly as it is up to >>> the compiler to decide what to do with the parameter here. >> >> I don't know much about the exact implementation details of GCC, but I >> find it very unlikely that GCC is allowed, or will ever actually do >> anything about a *used* variable that is marked as unused. That just >> sounds too crazy to be true. So I don't think we'll ever get screwed. > > I have in the back of my mind that we already screwed by this. I don't > have the details at hand so I can't proof it. > > If I ever run into this problem with efl I will bill you the number of > hours I had to work it out. Could easily be days for such a thing. :) Most likely the problem you remember is regarding the pure or const attributes, not the unused. If you declare the function as pure and then in reality it isn't, bad things will happen depending on the optimization level because the compiler may reuse a previous return value instead of calling the function again. I remember fixing one problem like this in E or EFL some years ago. Lucas De Marchi -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
