Re: [E-devel] [elementary]elm_widget: elm widget

[The Rasterman]

On Mon, 7 Jan 2013 21:04:41 +0900 Bluezery  said:

:(```
elm_widget.c: In function '_elm_widget_focus_region_show':
elm_widget.c:660:14: warning: implicit declaration of function
'ELM_SCROLLABLE_IFACE_GET' [-Wimplicit-function-declaration]
elm_widget.c:660:42: error: 's_iface' undeclared (first use in this function)
elm_widget.c:660:42: note: each undeclared identifier is reported only once for
each function it appears in
:(...

> It's final fix.  :)
> Previsouly, I do not considerthe case which is in the scroller in the
> scroller. Current logic is that:
> Find scroller in parent objects. And calculate region to focus in the
> scroller. And show focused object.  That's all.
> 
> 2013/1/7 Bluezery :
> > I have changed patch a little.
> > Region show should be performed only for the objects which implement
> > elm_wdg_focus_region_get(), such as entry.
> > Otherwise, do not show region the object when it is focused.
> >
> > 2013/1/5 Bluezery :
> >> Hello,
> >>
> >> I have made a patch for fixing region show of widget focus in scroller.
> >> Previously, region show is not correct if focused object is not in the
> >> viewport of ther scroller
> >> Because region show calculation is done only by evas object geometry.
> >> But scroller object can know the viewport region in the scroller. It
> >> is different from evas object geometry.
> >>
> >> In my patch,
> >> if focused object is requested to be shown, focused object calculates
> >> it itself (by elm_widget_focus_region_get)  or evas geometry is
> >> gained.
> >> If parent is not scroller, geometry is changed by this parent for
> >> showing this parent in the scroller if grand parent is scroller.
> >> If parent is scroller, it find out whether the object is in the
> >> viewport of the scroller object (parent) and region to be shown is
> >> calculated.
> >>
> >> Please review this patch.
> >>
> >> --
> >> BRs,
> >> Kim.
> >
> >
> >
> > --
> > BRs,
> > Kim.
> 
> 
> 
> -- 
> BRs,
> Kim.


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


--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] [Elementary] Patch to fix elementary list with separator

[The Rasterman]

On Wed, 2 Jan 2013 19:13:00 +0900 Daniel Juyung Seo  said:

> Oops Thiep, sorry I didn't review test_list.c
> So here are more comments.
> 
> 1. api_data
> api_data *api = calloc(1, sizeof(api_data));$
> 
> api_data is not used in test_list_separator() so remove it and related
> codes.
> 
> 2. test_list_separator(xxx) indentation
> Indentations for test_list_separator(xxx) are wrong.
> 
> +test_list_separator(void*data __UNUSED__,
> +  Evas_Object *obj __UNUSED__,
> +  void*event_info __UNUSED__)
> 
> Thanks.

i didnt see a followup from this in email... but some of the patch is in svn i
think at least.. is this done? :)

> Daniel Juyung Seo (SeoZ)
> 
> On Wed, Jan 2, 2013 at 6:53 PM, Daniel Juyung Seo wrote:
> 
> > Dear Thiep, thanks a lot for your bug fix.
> > There was an explicit bug on elm list separator.
> > And I have some comments.
> >
> > 1. elementary-1.7
> > Please support the same patches to elementary-1.7.
> >
> > 2. it->deleted checks
> > it->deleted checks in elm_list.c:600 is not needed.
> > It was already checked.
> >
> > 3. it->separator_themed
> > separator_themed is not needed.
> > it->fixed does the same job.
> >
> > 4. code structure
> > I think you can reuse some existing code.
> > Move 38 ~ 47 lines of your patch to the following parts and reuse the code.
> > if (!it->fixed) ...
> > If my explanation is ambigous I will do the refactoring once your code is
> > committed.
> >
> > Thanks.
> >
> > Daniel Juyung Seo (SeoZ)
> >
> >
> > On Sun, Dec 30, 2012 at 3:03 PM, Thiep Ha  wrote:
> >
> >> Hi all,
> >>
> >> I sent this patch before, but there is no reply.
> >> So, I resend it.
> >> Since separators in list are not correctly applied (always have same size
> >> with other items),
> >> this patch is sent to fix that.
> >> Could someone review it?
> >>
> >> Thanks,
> >> Thiep
> >>
> >>
> >>
> >> From: thiep ha 
> >> > Date: Sun, Dec 9, 2012 at 11:11 AM
> >> > Subject: [E-devel] [Patch] [Elementary] Patch to fix elementary list
> >> with
> >> > separator
> >> > To: "enlightenment-devel@lists.sourceforge.net" <
> >> > enlightenment-devel@lists.sourceforge.net>
> >> >
> >> >
> >> > Dear All,
> >> >
> >> > In elementary list, the separator is not correctly set.
> >> > I would like to send a patch to correct the list with separator.
> >> > I also add an example named "List Separator" to test it.
> >> >
> >> > Please review this patch.
> >> >
> >> > Best Regards,
> >> > Thiep Ha
> >> >
> >> >
> >>
> >>
> >> --
> >> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> >> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> >> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> >> MVPs and experts. ON SALE this month only -- learn more at:
> >> http://p.sf.net/sfu/learnmore_123012
> >> ___
> >> enlightenment-devel mailing list
> >> enlightenment-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>
> >>
> >
> --
> Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
> and much more. Keep your Java skills current with LearnJavaNow -
> 200+ hours of step-by-step video tutorials by Java experts.
> SALE $49.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122612 
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


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


--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [e-users] Korean E dinner

[The Rasterman]

On Wed, 13 Feb 2013 19:31:40 +0900 Daniel Juyung Seo 
said:

did someone mention this weekend? saturday? meet up... meat pies. guinness? or
we could try the belgian beer bar that sungwoo claims is in itaewon
somewhere... :)

> For the next E-Korea meeting, Hyoyoung suggested me this place.
> http://www.tonysitaewon.com/home.html
> AUSTRAILIAN.
> 
> I hope raster will like this place :)
> 
> Daniel Juyung Seo (SeoZ)
> 
> On Thu, Jan 10, 2013 at 4:01 PM, Carsten Haitzler wrote:
> 
> > On Thu, 10 Jan 2013 12:36:53 +0900 Cedric BAIL  said:
> >
> > > On Thu, Jan 10, 2013 at 10:11 AM, Sung W. Park 
> > wrote:
> > > > Raster & Hermet doing Gangnam style!  crazy!
> > > >
> > > > by the way, if you guys are gonna try Vatos, I suggest that you call
> > the
> > > > place and make a reservation (if possible)... they may be booked
> > already.
> > > > otherwise you're looking at an hour wait at least!  but the food is
> > > > awesome!
> > > >
> > > > http://blog.naver.com/gmdosk?Redirect=Log&logNo=70154958852
> > > >
> > > > If you're looking for something else, I also would like to recommend
> > "New
> > > > York Brick Oven Pizza" near Gangnam station.
> > > >
> > > > http://blog.naver.com/crom776?Redirect=Log&logNo=150148599787
> > > >
> > > > It's my favorite pizza place in Korea.  The owner was actually trained
> > in
> > > > the states and he imports his key ingredients from the states.
> > >
> > > Don't you know a real Italian pizza place ? :-)
> >
> > you and your paper-thin pizzas. you need to learn to like real thick
> > pizzas! om
> > nom nom!
> >
> >
> > http://s-ak.buzzfed.com/static/enhanced/terminal01/2010/8/9/17/enhanced-buzz-15964-1281389568-29.jpg
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am" --
> > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> >
> >
> >
> > --
> > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> > MVPs and experts. ON SALE this month only -- learn more at:
> > http://p.sf.net/sfu/learnmore_122712
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> --
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013 
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


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


--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] [Elementary] Patch to fix elementary list with separator

[Daniel Juyung Seo]

On Mon, Feb 18, 2013 at 5:13 PM, Carsten Haitzler wrote:

> On Wed, 2 Jan 2013 19:13:00 +0900 Daniel Juyung Seo 
> said:
>
> > Oops Thiep, sorry I didn't review test_list.c
> > So here are more comments.
> >
> > 1. api_data
> > api_data *api = calloc(1, sizeof(api_data));$
> >
> > api_data is not used in test_list_separator() so remove it and related
> > codes.
> >
> > 2. test_list_separator(xxx) indentation
> > Indentations for test_list_separator(xxx) are wrong.
> >
> > +test_list_separator(void*data __UNUSED__,
> > +  Evas_Object *obj __UNUSED__,
> > +  void*event_info __UNUSED__)
> >
> > Thanks.
>
>
Hello


> i didnt see a followup from this in email... but some of the patch is in
> svn i
> think at least.. is this done? :)
>

I guess you missed my reply.

>> Thanks in SVN!
>> Please modify ChangeLog and NEWS files when you fix a bug which was
included in the released version.
>> I did it for you this time.
>> http://trac.enlightenment.org/e/changeset/82040
>> http://trac.enlightenment.org/e/changeset/82041

Daniel Juyung Seo (SeoZ)


> > Daniel Juyung Seo (SeoZ)
> >
> > On Wed, Jan 2, 2013 at 6:53 PM, Daniel Juyung Seo  >wrote:
> >
> > > Dear Thiep, thanks a lot for your bug fix.
> > > There was an explicit bug on elm list separator.
> > > And I have some comments.
> > >
> > > 1. elementary-1.7
> > > Please support the same patches to elementary-1.7.
> > >
> > > 2. it->deleted checks
> > > it->deleted checks in elm_list.c:600 is not needed.
> > > It was already checked.
> > >
> > > 3. it->separator_themed
> > > separator_themed is not needed.
> > > it->fixed does the same job.
> > >
> > > 4. code structure
> > > I think you can reuse some existing code.
> > > Move 38 ~ 47 lines of your patch to the following parts and reuse the
> code.
> > > if (!it->fixed) ...
> > > If my explanation is ambigous I will do the refactoring once your code
> is
> > > committed.
> > >
> > > Thanks.
> > >
> > > Daniel Juyung Seo (SeoZ)
> > >
> > >
> > > On Sun, Dec 30, 2012 at 3:03 PM, Thiep Ha  wrote:
> > >
> > >> Hi all,
> > >>
> > >> I sent this patch before, but there is no reply.
> > >> So, I resend it.
> > >> Since separators in list are not correctly applied (always have same
> size
> > >> with other items),
> > >> this patch is sent to fix that.
> > >> Could someone review it?
> > >>
> > >> Thanks,
> > >> Thiep
> > >>
> > >>
> > >>
> > >> From: thiep ha 
> > >> > Date: Sun, Dec 9, 2012 at 11:11 AM
> > >> > Subject: [E-devel] [Patch] [Elementary] Patch to fix elementary list
> > >> with
> > >> > separator
> > >> > To: "enlightenment-devel@lists.sourceforge.net" <
> > >> > enlightenment-devel@lists.sourceforge.net>
> > >> >
> > >> >
> > >> > Dear All,
> > >> >
> > >> > In elementary list, the separator is not correctly set.
> > >> > I would like to send a patch to correct the list with separator.
> > >> > I also add an example named "List Separator" to test it.
> > >> >
> > >> > Please review this patch.
> > >> >
> > >> > Best Regards,
> > >> > Thiep Ha
> > >> >
> > >> >
> > >>
> > >>
> > >>
> --
> > >> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> > >> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills
> current
> > >> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> > >> MVPs and experts. ON SALE this month only -- learn more at:
> > >> http://p.sf.net/sfu/learnmore_123012
> > >> ___
> > >> enlightenment-devel mailing list
> > >> enlightenment-devel@lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >>
> > >>
> > >
> >
> --
> > Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
> > and much more. Keep your Java skills current with LearnJavaNow -
> > 200+ hours of step-by-step video tutorials by Java experts.
> > SALE $49.99 this month only -- learn more at:
> > http://p.sf.net/sfu/learnmore_122612
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/

Re: [E-devel] [EGIT] [core/efl] branch master updated. 04e660c5c76fa9168be08de1f979a1684c464154

[Stefan Schmidt]

Hello.

On 16/02/13 11:53, David Seikel wrote:
>
> Including Paulo's commit in that email was just wrong, so bug somewhere?

While Paulo is the author Cedric did commit the patch. Thus is was part 
of his changeset he pushed and thus it ended up in this mail.

regards
Stefan Schmidt


--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] SVN->Git Migration

[Tom Hacohen]

On 18/02/13 04:02, Daniel Juyung Seo wrote:
> And it'll be great if the title includes the first line of commit message.
> That should be way more useful.
> Thanks.

Correct me if I'm wrong, but I'm starting to think you guys would like 
to see the whole diff in the title.

--
Tom.

--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] SVN->Git Migration

[Michael Blumenkrantz]

ignore him, just make it as close to the previous svn mail subjects as
possible.

On Mon, Feb 18, 2013 at 9:21 AM, Tom Hacohen wrote:

> On 18/02/13 04:02, Daniel Juyung Seo wrote:
> > And it'll be great if the title includes the first line of commit
> message.
> > That should be way more useful.
> > Thanks.
>
> Correct me if I'm wrong, but I'm starting to think you guys would like
> to see the whole diff in the title.
>
> --
> Tom.
>
>
> --
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly
> thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now.
> http://goparallel.sourceforge.net/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] SVN->Git Migration

[Tom Hacohen]

On 18/02/13 09:26, Michael Blumenkrantz wrote:
> ignore him, just make it as close to the previous svn mail subjects as
> possible.

I never ignore SeoZ, but I'll disregard his suggestion here. I was 
planning on just making it the same as SVN was.

--
Tom.


--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] [Elementary] Patch to fix elementary list with separator

[The Rasterman]

On Mon, 18 Feb 2013 17:27:46 +0900 Daniel Juyung Seo 
said:

> On Mon, Feb 18, 2013 at 5:13 PM, Carsten Haitzler wrote:
> 
> > On Wed, 2 Jan 2013 19:13:00 +0900 Daniel Juyung Seo 
> > said:
> >
> > > Oops Thiep, sorry I didn't review test_list.c
> > > So here are more comments.
> > >
> > > 1. api_data
> > > api_data *api = calloc(1, sizeof(api_data));$
> > >
> > > api_data is not used in test_list_separator() so remove it and related
> > > codes.
> > >
> > > 2. test_list_separator(xxx) indentation
> > > Indentations for test_list_separator(xxx) are wrong.
> > >
> > > +test_list_separator(void*data __UNUSED__,
> > > +  Evas_Object *obj __UNUSED__,
> > > +  void*event_info __UNUSED__)
> > >
> > > Thanks.
> >
> >
> Hello
> 
> 
> > i didnt see a followup from this in email... but some of the patch is in
> > svn i
> > think at least.. is this done? :)
> >
> 
> I guess you missed my reply.

its not in my mailer in this thread.. did your mailer break the thread again?
(like oh so many people do making it impossible to follow threads). :)

> >> Thanks in SVN!
> >> Please modify ChangeLog and NEWS files when you fix a bug which was
> included in the released version.
> >> I did it for you this time.
> >> http://trac.enlightenment.org/e/changeset/82040
> >> http://trac.enlightenment.org/e/changeset/82041
> 
> Daniel Juyung Seo (SeoZ)
> 
> 
> > > Daniel Juyung Seo (SeoZ)
> > >
> > > On Wed, Jan 2, 2013 at 6:53 PM, Daniel Juyung Seo  > >wrote:
> > >
> > > > Dear Thiep, thanks a lot for your bug fix.
> > > > There was an explicit bug on elm list separator.
> > > > And I have some comments.
> > > >
> > > > 1. elementary-1.7
> > > > Please support the same patches to elementary-1.7.
> > > >
> > > > 2. it->deleted checks
> > > > it->deleted checks in elm_list.c:600 is not needed.
> > > > It was already checked.
> > > >
> > > > 3. it->separator_themed
> > > > separator_themed is not needed.
> > > > it->fixed does the same job.
> > > >
> > > > 4. code structure
> > > > I think you can reuse some existing code.
> > > > Move 38 ~ 47 lines of your patch to the following parts and reuse the
> > code.
> > > > if (!it->fixed) ...
> > > > If my explanation is ambigous I will do the refactoring once your code
> > is
> > > > committed.
> > > >
> > > > Thanks.
> > > >
> > > > Daniel Juyung Seo (SeoZ)
> > > >
> > > >
> > > > On Sun, Dec 30, 2012 at 3:03 PM, Thiep Ha  wrote:
> > > >
> > > >> Hi all,
> > > >>
> > > >> I sent this patch before, but there is no reply.
> > > >> So, I resend it.
> > > >> Since separators in list are not correctly applied (always have same
> > size
> > > >> with other items),
> > > >> this patch is sent to fix that.
> > > >> Could someone review it?
> > > >>
> > > >> Thanks,
> > > >> Thiep
> > > >>
> > > >>
> > > >>
> > > >> From: thiep ha 
> > > >> > Date: Sun, Dec 9, 2012 at 11:11 AM
> > > >> > Subject: [E-devel] [Patch] [Elementary] Patch to fix elementary list
> > > >> with
> > > >> > separator
> > > >> > To: "enlightenment-devel@lists.sourceforge.net" <
> > > >> > enlightenment-devel@lists.sourceforge.net>
> > > >> >
> > > >> >
> > > >> > Dear All,
> > > >> >
> > > >> > In elementary list, the separator is not correctly set.
> > > >> > I would like to send a patch to correct the list with separator.
> > > >> > I also add an example named "List Separator" to test it.
> > > >> >
> > > >> > Please review this patch.
> > > >> >
> > > >> > Best Regards,
> > > >> > Thiep Ha
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >>
> > --
> > > >> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> > > >> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills
> > current
> > > >> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> > > >> MVPs and experts. ON SALE this month only -- learn more at:
> > > >> http://p.sf.net/sfu/learnmore_123012
> > > >> ___
> > > >> enlightenment-devel mailing list
> > > >> enlightenment-devel@lists.sourceforge.net
> > > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > >>
> > > >>
> > > >
> > >
> > --
> > > Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
> > > and much more. Keep your Java skills current with LearnJavaNow -
> > > 200+ hours of step-by-step video tutorials by Java experts.
> > > SALE $49.99 this month only -- learn more at:
> > > http://p.sf.net/sfu/learnmore_122612
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >
> >
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am" --
> > The Rasterman (Carsten Haitzler)   

Re: [E-devel] SVN->Git Migration

[Guillaume Friloux]

On 18/02/2013 10:21, Tom Hacohen wrote:

On 18/02/13 04:02, Daniel Juyung Seo wrote:

And it'll be great if the title includes the first line of commit message.
That should be way more useful.
Thanks.

Correct me if I'm wrong, but I'm starting to think you guys would like
to see the whole diff in the title.



Great idea! please also add my local weather please.
<>--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] SVN->Git Migration

[Stefan Schmidt]

Hello.

On 18/02/13 09:21, Tom Hacohen wrote:
> On 18/02/13 04:02, Daniel Juyung Seo wrote:
>> And it'll be great if the title includes the first line of commit
> message.
>> That should be way more useful.
>> Thanks.
>
> Correct me if I'm wrong, but I'm starting to think you guys would like
> to see the whole diff in the title.

Come on. Take a step back and look at the commit email subject line as 
we have it right now:

[EGIT] [core/efl] branch master updated. 
04e660c5c76fa9168be08de1f979a1684c464154

[EGIT] Might be needed for people that can or want not filter on message 
headers.

[core/efl] Gives the repo. Useful.

branch master updated: I argued before that commit mails should only be 
send for the master branch. Everything else is only interesting for a 
small group of people and they will pull and look at the specific 
branches on their own.

git hash: Not useful in the title I would argue. Gives you zero 
informations about what was changed. Needed in the body for sure, but 
not in the subject.

I would propose:

[EGIT] [core/efl] First line of commit message.

The body does then have the full commit message, the hash as well as a 
shortlog before the complete diff comes in.

And yes that means one commit should result in one mail.

regards
Stefan Schmidt

--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] branch master updated. 04e660c5c76fa9168be08de1f979a1684c464154

[David Seikel]

On Mon, 18 Feb 2013 09:07:29 + Stefan Schmidt
 wrote:

> Hello.
> 
> On 16/02/13 11:53, David Seikel wrote:
> >
> > Including Paulo's commit in that email was just wrong, so bug
> > somewhere?
> 
> While Paulo is the author Cedric did commit the patch. Thus is was
> part of his changeset he pushed and thus it ended up in this mail.

Ah that makes sense.

-- 
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
--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] SVN->Git Migration

[Tom Hacohen]

On 18/02/13 09:36, Stefan Schmidt wrote:
> Hello.
>
> On 18/02/13 09:21, Tom Hacohen wrote:
>> On 18/02/13 04:02, Daniel Juyung Seo wrote:
>>> And it'll be great if the title includes the first line of commit
>> message.
>>> That should be way more useful.
>>> Thanks.
>>
>> Correct me if I'm wrong, but I'm starting to think you guys would like
>> to see the whole diff in the title.
>
> Come on. Take a step back and look at the commit email subject line as
> we have it right now:
>
> [EGIT] [core/efl] branch master updated.
> 04e660c5c76fa9168be08de1f979a1684c464154
>
> [EGIT] Might be needed for people that can or want not filter on message
> headers.
>
> [core/efl] Gives the repo. Useful.
>
> branch master updated: I argued before that commit mails should only be
> send for the master branch. Everything else is only interesting for a
> small group of people and they will pull and look at the specific
> branches on their own.
>
> git hash: Not useful in the title I would argue. Gives you zero
> informations about what was changed. Needed in the body for sure, but
> not in the subject.
>
> I would propose:
>
> [EGIT] [core/efl] First line of commit message.
>
> The body does then have the full commit message, the hash as well as a
> shortlog before the complete diff comes in.
>
> And yes that means one commit should result in one mail.

Yes, most of that will be there anyway, I was just joking... You are 
seating by my side, if it wasn't for the huge noise-cancelling 
headphones you have on your head, you've heard me and Daniel talking 
about it 10 minutes ago.

--
Tom.


--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] SVN->Git Migration

[Michael Blumenkrantz]

maybe he's writing a mail about it so that I can read it from my quarantine

On Mon, Feb 18, 2013 at 9:45 AM, Tom Hacohen wrote:

> On 18/02/13 09:36, Stefan Schmidt wrote:
> > Hello.
> >
> > On 18/02/13 09:21, Tom Hacohen wrote:
> >> On 18/02/13 04:02, Daniel Juyung Seo wrote:
> >>> And it'll be great if the title includes the first line of commit
> >> message.
> >>> That should be way more useful.
> >>> Thanks.
> >>
> >> Correct me if I'm wrong, but I'm starting to think you guys would like
> >> to see the whole diff in the title.
> >
> > Come on. Take a step back and look at the commit email subject line as
> > we have it right now:
> >
> > [EGIT] [core/efl] branch master updated.
> > 04e660c5c76fa9168be08de1f979a1684c464154
> >
> > [EGIT] Might be needed for people that can or want not filter on message
> > headers.
> >
> > [core/efl] Gives the repo. Useful.
> >
> > branch master updated: I argued before that commit mails should only be
> > send for the master branch. Everything else is only interesting for a
> > small group of people and they will pull and look at the specific
> > branches on their own.
> >
> > git hash: Not useful in the title I would argue. Gives you zero
> > informations about what was changed. Needed in the body for sure, but
> > not in the subject.
> >
> > I would propose:
> >
> > [EGIT] [core/efl] First line of commit message.
> >
> > The body does then have the full commit message, the hash as well as a
> > shortlog before the complete diff comes in.
> >
> > And yes that means one commit should result in one mail.
>
> Yes, most of that will be there anyway, I was just joking... You are
> seating by my side, if it wasn't for the huge noise-cancelling
> headphones you have on your head, you've heard me and Daniel talking
> about it 10 minutes ago.
>
> --
> Tom.
>
>
>
> --
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly
> thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now.
> http://goparallel.sourceforge.net/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] SVN->Git Migration

[David Seikel]

On Mon, 18 Feb 2013 09:45:54 + Tom Hacohen
 wrote:

> I was just joking... You are seating by my side, if it wasn't for the
> huge noise-cancelling headphones you have on your head, you've heard
> me and Daniel talking about it 10 minutes ago.

lol

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] SVN->Git Migration

[Daniel Willmann]

On 18/02/13 01:14, ChunEon Park wrote:
> Could it possible to make git mail title messages to be more meaningful?
> 
> i.e) [core/efl] xxxmaster updated. f27ff2fbf31a01c2f8d98e773bed6cc4298749bd
>  -> [core/efl/evas] xxxmaster updated. 
> f27ff2fbf31a01c2f8d98e773bed6cc4298749bd

I think after some discussion we all agree that the commit mails and
titles need to change.

I believe we have a sort of consensus now that we need to:
* send one mail per commit
* change the subject of the mail to include author and first line of
  commit message
  so: [EGIT] [core/efl] eina: fix siginfo detection (Cedric BAIL)
* If we send mails for more than just master we should include the
  branch in the commit message

Are we in favour of sending mails for all branches or just for master?
Anything else I missed?

> If the title shows any detailed core lib name that was changed, it would be 
> better to know what is changed in abstractly.

I don't think that we can easily do that. We know the repository, but
figuring out the component that changed is harder. What I am in favour
of is prefixing the first line of the commit message with the part
you're actually working on. (See example above)


Regards,
Daniel

--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] SVN->Git Migration

[Iván Briano]

On Mon, Feb 18, 2013 at 6:58 AM, Daniel Willmann  wrote:
> On 18/02/13 01:14, ChunEon Park wrote:
>> Could it possible to make git mail title messages to be more meaningful?
>>
>> i.e) [core/efl] xxxmaster updated. f27ff2fbf31a01c2f8d98e773bed6cc4298749bd
>>  -> [core/efl/evas] xxxmaster updated.
>> f27ff2fbf31a01c2f8d98e773bed6cc4298749bd
>
> I think after some discussion we all agree that the commit mails and
> titles need to change.
>
> I believe we have a sort of consensus now that we need to:
> * send one mail per commit
> * change the subject of the mail to include author and first line of
>   commit message
>   so: [EGIT] [core/efl] eina: fix siginfo detection (Cedric BAIL)
> * If we send mails for more than just master we should include the
>   branch in the commit message
>
> Are we in favour of sending mails for all branches or just for master?
> Anything else I missed?
>

Once we have backporting branches in git too it might be useful to have mails
for those, but I'm not sure other cases matter here.

>> If the title shows any detailed core lib name that was changed, it would be
>> better to know what is changed in abstractly.
>
> I don't think that we can easily do that. We know the repository, but
> figuring out the component that changed is harder. What I am in favour
> of is prefixing the first line of the commit message with the part
> you're actually working on. (See example above)
>
>
> Regards,
> Daniel
>
> --
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now. http://goparallel.sourceforge.net/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] SVN->Git Migration

[Daniel Willmann]

On 18/02/13 10:07, Ivan Briano wrote:
> On Mon, Feb 18, 2013 at 6:58 AM, Daniel Willmann 
> wrote:
>> Are we in favour of sending mails for all branches or just for master?
>> Anything else I missed?

> Once we have backporting branches in git too it might be useful to have
> mails
> for those, but I'm not sure other cases matter here.

True. So send mails for all branches but those under devs/*


Regards,
Daniel


--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] SVN->Git Migration

[The Rasterman]

On Mon, 18 Feb 2013 09:58:55 + Daniel Willmann 
said:

> On 18/02/13 01:14, ChunEon Park wrote:
> > Could it possible to make git mail title messages to be more meaningful?
> > 
> > i.e) [core/efl] xxxmaster updated. f27ff2fbf31a01c2f8d98e773bed6cc4298749bd
> >  -> [core/efl/evas] xxxmaster updated. 
> > f27ff2fbf31a01c2f8d98e773bed6cc4298749bd
> 
> I think after some discussion we all agree that the commit mails and
> titles need to change.
> 
> I believe we have a sort of consensus now that we need to:
> * send one mail per commit
> * change the subject of the mail to include author and first line of
>   commit message
>   so: [EGIT] [core/efl] eina: fix siginfo detection (Cedric BAIL)
> * If we send mails for more than just master we should include the
>   branch in the commit message

can we have subject have the dirs affected like [src/lib/eina src/lib/eet] etc.
- a list of them? 

> Are we in favour of sending mails for all branches or just for master?
> Anything else I missed?
> 
> > If the title shows any detailed core lib name that was changed, it would be 
> > better to know what is changed in abstractly.
> 
> I don't think that we can easily do that. We know the repository, but
> figuring out the component that changed is harder. What I am in favour
> of is prefixing the first line of the commit message with the part
> you're actually working on. (See example above)
> 
> 
> Regards,
> Daniel
> 
> --
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
> is your hub for all things parallel software development, from weekly thought 
> leadership blogs to news, videos, case studies, tutorials, tech docs, 
> whitepapers, evaluation guides, and opinion stories. Check out the most 
> recent posts - join the conversation now. http://goparallel.sourceforge.net/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


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


--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] SVN->Git Migration

[Tom Hacohen]

On 18/02/13 10:07, Iván Briano wrote:
> On Mon, Feb 18, 2013 at 6:58 AM, Daniel Willmann  
> wrote:
>> On 18/02/13 01:14, ChunEon Park wrote:
>>> Could it possible to make git mail title messages to be more meaningful?
>>>
>>> i.e) [core/efl] xxxmaster updated. f27ff2fbf31a01c2f8d98e773bed6cc4298749bd
>>>   -> [core/efl/evas] xxxmaster updated.
>>> f27ff2fbf31a01c2f8d98e773bed6cc4298749bd
>>
>> I think after some discussion we all agree that the commit mails and
>> titles need to change.
>>
>> I believe we have a sort of consensus now that we need to:
>> * send one mail per commit
>> * change the subject of the mail to include author and first line of
>>commit message
>>so: [EGIT] [core/efl] eina: fix siginfo detection (Cedric BAIL)
>> * If we send mails for more than just master we should include the
>>branch in the commit message
>>
>> Are we in favour of sending mails for all branches or just for master?
>> Anything else I missed?
>>
>
> Once we have backporting branches in git too it might be useful to have mails
> for those, but I'm not sure other cases matter here.
>

To elaborate more on what Daniel has mentioned:
The plan is actually to send updates on all branches except for dev 
branches, so all branches will get update mails except for devs/*.

--
Tom.



--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [PATCH] elm_index: add omit feature

[Jaeun Choi]

This patch adds omit feature to elm_index.
 
- not support horizontal mode 
- enabled when at least 3 items can be displayed (first and last items are not 
omitted)
- not work when having too many items (patch line 270)
 
I appreciate your review. Thanks.
 
Index: elm_widget_index.h
===
--- elm_widget_index.h	(revision 83941)
+++ elm_widget_index.h	(working copy)
@@ -35,6 +35,9 @@ struct _Elm_Index_Smart_Data
Eina_Bool horizontal : 1;
Eina_Bool autohide_disabled : 1;
Eina_Bool indicator_disabled : 1;
+
+   Eina_Bool omit_enabled : 1;
+   Eina_List*omit;
 };
 
 typedef struct _Elm_Index_Item   Elm_Index_Item;
@@ -47,8 +50,18 @@ struct _Elm_Index_Item
Evas_Smart_Cb func;
 
Eina_Bool selected : 1;
+
+   Eina_List	*omitted;
+   Elm_Index_Item   *head;
 };
 
+typedef struct _Elm_Index_Omit Elm_Index_Omit;
+struct _Elm_Index_Omit
+{
+   int offset;
+   int count;
+};
+
 /**
  * @}
  */
Index: elm_index.c
===
--- elm_index.c	(revision 83941)
+++ elm_index.c	(working copy)
@@ -112,32 +112,142 @@ _access_widget_item_register(Elm_Index_Item *it)
_elm_access_callback_set(ai, ELM_ACCESS_INFO, _access_info_cb, it);
 }
 
+static void
+_omit_calc(void *data, int num_of_items, int max_num_of_items)
+{
+   Elm_Index_Smart_Data *sd = data;
+   int max_group_num, num_of_extra_items, i, g, size, sum;
+   Elm_Index_Omit *o;
+   Elm_Index_Item *it;
+   Eina_List *l;
+
+   EINA_LIST_FREE(sd->omit, o)
+  free(o);
+
+   EINA_LIST_FOREACH(sd->items, l, it)
+ {
+if (it->omitted)
+  it->omitted = eina_list_free(it->omitted);
+if (it->head) it->head = NULL;
+ }
+
+   if ((max_num_of_items < 3) || (num_of_items <= max_num_of_items)) return;
+
+   max_group_num = (max_num_of_items - 1) / 2;
+   num_of_extra_items = num_of_items - max_num_of_items;
+
+   int group_pos[max_group_num];
+   int omit_info[max_num_of_items];
+
+   if (num_of_extra_items >= max_group_num)
+ {
+g = 1;
+for (i = 0; i < max_group_num; i++)
+  {
+ group_pos[i] = g;
+ g += 2;
+  }
+ }
+   else
+ {
+size = max_num_of_items / (num_of_extra_items + 1);
+g = size;
+for (i = 0; i < num_of_extra_items; i++)
+  {
+ group_pos[i] = g;
+ g += size;
+  }
+ }
+   for (i = 0; i < max_num_of_items; i++)
+ omit_info[i] = 1;
+   for (i = 0; i < num_of_extra_items; i++)
+ omit_info[group_pos[i % max_group_num]]++;
+
+   g = 0;
+   sum = 0;
+   for (i = 0; i < max_num_of_items; i++)
+ {
+if (omit_info[i] > 1)
+  {
+ o = (Elm_Index_Omit *)malloc(sizeof(Elm_Index_Omit));
+ o->offset = sum;
+ o->count = omit_info[i];
+ sd->omit = eina_list_append(sd->omit, o);
+ g++;
+  }
+sum += omit_info[i];
+ }
+}
+
 // FIXME: always have index filled
 static void
 _index_box_auto_fill(Evas_Object *obj,
  Evas_Object *box,
  int level)
 {
-   int i = 0;
+   int i = 0, max_num_of_items = 0, num_of_items = 0, g = 0, skip = 0;
Eina_List *l;
Eina_Bool rtl;
-   Elm_Index_Item *it;
-   Evas_Coord mw, mh, w, h;
+   Elm_Index_Item *it, *head = NULL;
+   Evas_Coord mw, mh, ih;
+   Evas_Object *o;
+   Elm_Index_Omit *om;
 
ELM_INDEX_DATA_GET(obj, sd);
 
if (sd->level_active[level]) return;
 
+   Elm_Widget_Smart_Data *wd = eo_data_get(obj, ELM_OBJ_WIDGET_CLASS);
+   evas_object_geometry_get(wd->resize_obj, NULL, NULL, NULL, &ih);
+
rtl = elm_widget_mirrored_get(obj);
-   evas_object_geometry_get(box, NULL, NULL, &w, &h);
 
+   if (sd->omit_enabled)
+ {
+o = edje_object_add(evas_object_evas_get(obj));
+elm_widget_theme_object_set
+   (obj, o, "index", "item/vertical",
+elm_widget_style_get(obj));
+
+edje_object_size_min_restricted_calc(o, NULL, &mh, 0, 0);
+
+EINA_LIST_FOREACH(sd->items, l, it)
+   if (it->level == level) num_of_items++;
+
+if (mh != 0)
+  max_num_of_items = ih / mh;
+
+_omit_calc(sd, num_of_items, max_num_of_items);
+ }
+
+   om = eina_list_nth(sd->omit, g);
EINA_LIST_FOREACH(sd->items, l, it)
  {
-Evas_Object *o;
 const char *stacking;
 
 if (it->level != level) continue;
 
+if (om && i == om->offset)
+  {
+ skip = om->count;
+ skip--;
+ head = it;
+ it->head = head;
+ head->omitted = eina_list_append(head->omitted, it);
+ om = eina_list_nth(sd->omit, ++g);
+  }
+else if (skip > 0)
+  {
+ skip--;
+ i++;
+ if (head)
+   {
+  it->head = head;
+  

Re: [E-devel] SVN->Git Migration

[Daniel Willmann]

On 16/02/13 06:42, Jérôme Pinot wrote:
>> On Fri, 15 Feb 2013 11:56:06 -0200 Rafael Antognolli
>>  wrote:
>>> I know that this is not a poll, but I particularly prefer rebased
>>> branches/commits too.
> 
> LWN has a neat article about the git rebase thing:
> http://lwn.net/Articles/328436/
> 
> "Thou Shalt Not Rebase Trees With History Visible To Others"

I agree with this which is why master and other branches are
fast-forward only. Local branches are not "visible to others" in any
case, that's pretty clear.

What's not so clear is the developer branches in devs/user/

The link you mentioned states:
"""
[I]f you're still in the "git rebase" phase, you don't push it out. If
it's not ready, you send patches around, or use private git trees (just
as a "patch series replacement") that you don't tell the public at large
about.
"""

I think we should handle them as private and people should not depend on
them (the alternative is to have developers use private repositories
which is a bit more complicated).


Regards,
Daniel


--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Query] Controlling further eventing on an edje draggable part programmatically

[Rajeev Ranjan]

Hi Raster,
> --- Original Message ---
> Sender : Carsten Haitzler
> Date : Feb 18, 2013 12:39 (GMT+09:00)
> Title : Re: [E-devel] [Query] Controlling further eventing on an edje 
> draggable part programmatically
> 
> On Fri, 15 Feb 2013 11:43:21 + (GMT) Rajeev Ranjan 
> said:
> 
>> Hi,
>> > --- Original Message ---
>> > Sender : Carsten Haitzler
>> > Date : Feb 15, 2013 20:15 (GMT+09:00)
>> >Title : Re: [E-devel] [Query] Controlling further eventing on an edje
>> >draggable part programmatically
>> > 
>> > On Fri, 15 Feb 2013 11:02:13 + (GMT) Rajeev Ranjan 
>> said:
>> >
>> >> Hi,
>> >>   I have a requirement where on certain event like on resize I dont want 
>> >> to
>> >> keep allowing dragging for an edje draggable part even if 
>> >> mouse,up/touch,up
>> >> has not yet been done after mouse,down.
>> >
>> > this sounds odd. can you please expand on why you need/want this?
>> >
>>Basically my requirement is related to elm_panes(vertical) where in
>> landscape mode we have both contents set and in portrait mode, we have single
>> content set and left size set to 1.0 to hide the other content area. Now when
>> we tap on handler in panes in landscape mode and without lifting finger,
>> rotate the device to portrait mode, then still the handler can be dragged. In
>> this case, it is unwanted if there is a single content in portrait mode and
>> the other one is unset when mode is portrait.
>
> hmmm ok - it smells more to me that you need a feature in the elm panes widget
> to be able to go in "show only one element" mode (and maybe choose that
> element - top/bottom etc.) it sounds to me like you then want to emit a signal
> to the panes edje obj to tell it to go into "1 content only" and indicate 
> which
> one, or to go back to normal "2 items".
Yes, this is infact the actual requirement in panes however this kind of 
requirement is not limited to panes only. E.g. in slider as well, we don't want 
to have the dragging happening on rotation as
because of window resize the touch point position will change and will be 
having different position than that of indicator.
Further I made the handler(draggable part) invisible when there be a single 
content(the other one is unset on rotation), still the handler continued to 
take events[At the time of drag start, handler was visible].
Please tell me if there can be a way by which we can stop further dragging 
programmatically for draggable part.

 
> 
> > >> For this, I used pointer_mode: NOGRAB for draggable part but it didn't 
> > >> work
> > >> in case of draggable as it kept taking drag events even if the 
> > >> mouse/touch
> > >> was outside draggable geometry. Even synthesizing mouse,up,1 with source
> > >> "" in edc had no effect and drag event was continuously
> > >> going to the draggable part.
> > >
> > > nograb is a totally different thing to what you want i think.. so it's not
> > > going to help :)
> > >>
> > I tested pointer_mode with NOGRAB option for parts other than draggable and
> > found that the events outside the part geometry are ignored in this case
> > (including mouse,up), so I thought that may be this should work with
> > draggable as well.
> > 
> > >> Please let me know if there is any way we can control this (avoiding
> > >> further drag event for a drag part) programmatically.
> > >> 
> > >> Thank you.
> > >> Regards,
> > >> Rajeev
> > >> --

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

Thank you.
Regards,
Rajeev
--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] [Elementary] Patch to fix elementary list with separator

[Daniel Juyung Seo]

On Mon, Feb 18, 2013 at 6:29 PM, Carsten Haitzler wrote:

> On Mon, 18 Feb 2013 17:27:46 +0900 Daniel Juyung Seo  >
> said:
>
> > On Mon, Feb 18, 2013 at 5:13 PM, Carsten Haitzler  >wrote:
> >
> > > On Wed, 2 Jan 2013 19:13:00 +0900 Daniel Juyung Seo <
> seojuyu...@gmail.com>
> > > said:
> > >
> > > > Oops Thiep, sorry I didn't review test_list.c
> > > > So here are more comments.
> > > >
> > > > 1. api_data
> > > > api_data *api = calloc(1, sizeof(api_data));$
> > > >
> > > > api_data is not used in test_list_separator() so remove it and
> related
> > > > codes.
> > > >
> > > > 2. test_list_separator(xxx) indentation
> > > > Indentations for test_list_separator(xxx) are wrong.
> > > >
> > > > +test_list_separator(void*data __UNUSED__,
> > > > +  Evas_Object *obj __UNUSED__,
> > > > +  void*event_info __UNUSED__)
> > > >
> > > > Thanks.
> > >
> > >
> > Hello
> >
> >
> > > i didnt see a followup from this in email... but some of the patch is
> in
> > > svn i
> > > think at least.. is this done? :)
> > >
> >
> > I guess you missed my reply.
>
> its not in my mailer in this thread.. did your mailer break the thread
> again?
> (like oh so many people do making it impossible to follow threads). :)
>


Well I don't think so. Gmail works very fine with this kind of mail thread.
The title is still "Re: [E-devel] [PATCH] [Elementary] Patch to fix
elementary list with separator".
It should work.

Daniel Juyung Seo (SeoZ)



>
> > >> Thanks in SVN!
> > >> Please modify ChangeLog and NEWS files when you fix a bug which was
> > included in the released version.
> > >> I did it for you this time.
> > >> http://trac.enlightenment.org/e/changeset/82040<
> http://trac.enlightenment.org/e/changeset/82040>
> > >> http://trac.enlightenment.org/e/changeset/82041
> >
> > Daniel Juyung Seo (SeoZ)
> >
> >
> > > > Daniel Juyung Seo (SeoZ)
> > > >
> > > > On Wed, Jan 2, 2013 at 6:53 PM, Daniel Juyung Seo <
> seojuyu...@gmail.com
> > > >wrote:
> > > >
> > > > > Dear Thiep, thanks a lot for your bug fix.
> > > > > There was an explicit bug on elm list separator.
> > > > > And I have some comments.
> > > > >
> > > > > 1. elementary-1.7
> > > > > Please support the same patches to elementary-1.7.
> > > > >
> > > > > 2. it->deleted checks
> > > > > it->deleted checks in elm_list.c:600 is not needed.
> > > > > It was already checked.
> > > > >
> > > > > 3. it->separator_themed
> > > > > separator_themed is not needed.
> > > > > it->fixed does the same job.
> > > > >
> > > > > 4. code structure
> > > > > I think you can reuse some existing code.
> > > > > Move 38 ~ 47 lines of your patch to the following parts and reuse
> the
> > > code.
> > > > > if (!it->fixed) ...
> > > > > If my explanation is ambigous I will do the refactoring once your
> code
> > > is
> > > > > committed.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > Daniel Juyung Seo (SeoZ)
> > > > >
> > > > >
> > > > > On Sun, Dec 30, 2012 at 3:03 PM, Thiep Ha 
> wrote:
> > > > >
> > > > >> Hi all,
> > > > >>
> > > > >> I sent this patch before, but there is no reply.
> > > > >> So, I resend it.
> > > > >> Since separators in list are not correctly applied (always have
> same
> > > size
> > > > >> with other items),
> > > > >> this patch is sent to fix that.
> > > > >> Could someone review it?
> > > > >>
> > > > >> Thanks,
> > > > >> Thiep
> > > > >>
> > > > >>
> > > > >>
> > > > >> From: thiep ha 
> > > > >> > Date: Sun, Dec 9, 2012 at 11:11 AM
> > > > >> > Subject: [E-devel] [Patch] [Elementary] Patch to fix elementary
> list
> > > > >> with
> > > > >> > separator
> > > > >> > To: "enlightenment-devel@lists.sourceforge.net" <
> > > > >> > enlightenment-devel@lists.sourceforge.net>
> > > > >> >
> > > > >> >
> > > > >> > Dear All,
> > > > >> >
> > > > >> > In elementary list, the separator is not correctly set.
> > > > >> > I would like to send a patch to correct the list with separator.
> > > > >> > I also add an example named "List Separator" to test it.
> > > > >> >
> > > > >> > Please review this patch.
> > > > >> >
> > > > >> > Best Regards,
> > > > >> > Thiep Ha
> > > > >> >
> > > > >> >
> > > > >>
> > > > >>
> > > > >>
> > >
> --
> > > > >> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5,
> CSS,
> > > > >> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills
> > > current
> > > > >> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> > > > >> MVPs and experts. ON SALE this month only -- learn more at:
> > > > >> http://p.sf.net/sfu/learnmore_123012
> > > > >> ___
> > > > >> enlightenment-devel mailing list
> > > > >> enlightenment-devel@lists.sourceforge.net
> > > > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > > >>
> > > > >>
> > > > >
> > > >
> > >
> --
> > > > Master Java SE,

Re: [E-devel] [PATCH] [Elementary] Patch to fix elementary list with separator

[The Rasterman]

On Mon, 18 Feb 2013 20:56:51 +0900 Daniel Juyung Seo 
said:

> On Mon, Feb 18, 2013 at 6:29 PM, Carsten Haitzler wrote:
> 
> > On Mon, 18 Feb 2013 17:27:46 +0900 Daniel Juyung Seo  > >
> > said:
> >
> > > On Mon, Feb 18, 2013 at 5:13 PM, Carsten Haitzler  > >wrote:
> > >
> > > > On Wed, 2 Jan 2013 19:13:00 +0900 Daniel Juyung Seo <
> > seojuyu...@gmail.com>
> > > > said:
> > > >
> > > > > Oops Thiep, sorry I didn't review test_list.c
> > > > > So here are more comments.
> > > > >
> > > > > 1. api_data
> > > > > api_data *api = calloc(1, sizeof(api_data));$
> > > > >
> > > > > api_data is not used in test_list_separator() so remove it and
> > related
> > > > > codes.
> > > > >
> > > > > 2. test_list_separator(xxx) indentation
> > > > > Indentations for test_list_separator(xxx) are wrong.
> > > > >
> > > > > +test_list_separator(void*data __UNUSED__,
> > > > > +  Evas_Object *obj __UNUSED__,
> > > > > +  void*event_info __UNUSED__)
> > > > >
> > > > > Thanks.
> > > >
> > > >
> > > Hello
> > >
> > >
> > > > i didnt see a followup from this in email... but some of the patch is
> > in
> > > > svn i
> > > > think at least.. is this done? :)
> > > >
> > >
> > > I guess you missed my reply.
> >
> > its not in my mailer in this thread.. did your mailer break the thread
> > again?
> > (like oh so many people do making it impossible to follow threads). :)
> 
> 
> Well I don't think so. Gmail works very fine with this kind of mail thread.
> The title is still "Re: [E-devel] [PATCH] [Elementary] Patch to fix
> elementary list with separator".
> It should work.

thieps mail broke it. clients break thread by removing the In-Reply-To field in
the header. this is the header that for the past what 15.. 20  years has been
used by mail clients to figure out threads. it knows WHAT mail id this was in
reply to... a mailer will assign a unique id with Message-ID when you send it,
so mail clients can "trace" these id's and reply tos and do a thread correctly
and repliably. thats how it can do multiple levels of nesting etc. too.

gmail GUESSES by the subject being the same with an Re: that it might be a
thread. but it cant know exactly what you reply to like a proper nesting
thread unless you use such mail id's.

bad mail clients are unsociable and break such threads by simply posting a whole
new mail to the list with no context/reference what it is in reply to. it
breaks other peoples ability to track the conversation properly even though
for like 20 years clients have been playing nice. now they just don't bother
and are rude and remove such threading info.

> > > >> Thanks in SVN!
> > > >> Please modify ChangeLog and NEWS files when you fix a bug which was
> > > included in the released version.
> > > >> I did it for you this time.
> > > >> http://trac.enlightenment.org/e/changeset/82040<
> > http://trac.enlightenment.org/e/changeset/82040>
> > > >> http://trac.enlightenment.org/e/changeset/82041
> > >
> > > Daniel Juyung Seo (SeoZ)
> > >
> > >
> > > > > Daniel Juyung Seo (SeoZ)
> > > > >
> > > > > On Wed, Jan 2, 2013 at 6:53 PM, Daniel Juyung Seo <
> > seojuyu...@gmail.com
> > > > >wrote:
> > > > >
> > > > > > Dear Thiep, thanks a lot for your bug fix.
> > > > > > There was an explicit bug on elm list separator.
> > > > > > And I have some comments.
> > > > > >
> > > > > > 1. elementary-1.7
> > > > > > Please support the same patches to elementary-1.7.
> > > > > >
> > > > > > 2. it->deleted checks
> > > > > > it->deleted checks in elm_list.c:600 is not needed.
> > > > > > It was already checked.
> > > > > >
> > > > > > 3. it->separator_themed
> > > > > > separator_themed is not needed.
> > > > > > it->fixed does the same job.
> > > > > >
> > > > > > 4. code structure
> > > > > > I think you can reuse some existing code.
> > > > > > Move 38 ~ 47 lines of your patch to the following parts and reuse
> > the
> > > > code.
> > > > > > if (!it->fixed) ...
> > > > > > If my explanation is ambigous I will do the refactoring once your
> > code
> > > > is
> > > > > > committed.
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > Daniel Juyung Seo (SeoZ)
> > > > > >
> > > > > >
> > > > > > On Sun, Dec 30, 2012 at 3:03 PM, Thiep Ha 
> > wrote:
> > > > > >
> > > > > >> Hi all,
> > > > > >>
> > > > > >> I sent this patch before, but there is no reply.
> > > > > >> So, I resend it.
> > > > > >> Since separators in list are not correctly applied (always have
> > same
> > > > size
> > > > > >> with other items),
> > > > > >> this patch is sent to fix that.
> > > > > >> Could someone review it?
> > > > > >>
> > > > > >> Thanks,
> > > > > >> Thiep
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> From: thiep ha 
> > > > > >> > Date: Sun, Dec 9, 2012 at 11:11 AM
> > > > > >> > Subject: [E-devel] [Patch] [Elementary] Patch to fix elementary
> > list
> > > > > >> with
> > > > > >> > separator
> > > > > >> > To: "enlightenment-devel@lists.sourceforge.net" <
> > > > > >> > enlightenment-devel@lists.sourceforge.n

Re: [E-devel] [PATCH] [Elementary] Patch to fix elementary list with separator

[David Seikel]

On Mon, 18 Feb 2013 21:24:47 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Mon, 18 Feb 2013 20:56:51 +0900 Daniel Juyung Seo
>  said:
> 
> > On Mon, Feb 18, 2013 at 6:29 PM, Carsten Haitzler
> > wrote:
> > 
> > > On Mon, 18 Feb 2013 17:27:46 +0900 Daniel Juyung Seo
> > >  > > >
> > > said:
> > >
> > > > On Mon, Feb 18, 2013 at 5:13 PM, Carsten Haitzler
> > > >  > > >wrote:
> > > >
> > > > > On Wed, 2 Jan 2013 19:13:00 +0900 Daniel Juyung Seo <
> > > seojuyu...@gmail.com>
> > > > > said:
> > > > >
> > > > > > Oops Thiep, sorry I didn't review test_list.c
> > > > > > So here are more comments.
> > > > > >
> > > > > > 1. api_data
> > > > > > api_data *api = calloc(1, sizeof(api_data));$
> > > > > >
> > > > > > api_data is not used in test_list_separator() so remove it
> > > > > > and
> > > related
> > > > > > codes.
> > > > > >
> > > > > > 2. test_list_separator(xxx) indentation
> > > > > > Indentations for test_list_separator(xxx) are wrong.
> > > > > >
> > > > > > +test_list_separator(void*data __UNUSED__,
> > > > > > +  Evas_Object *obj __UNUSED__,
> > > > > > +  void*event_info __UNUSED__)
> > > > > >
> > > > > > Thanks.
> > > > >
> > > > >
> > > > Hello
> > > >
> > > >
> > > > > i didnt see a followup from this in email... but some of the
> > > > > patch is
> > > in
> > > > > svn i
> > > > > think at least.. is this done? :)
> > > > >
> > > >
> > > > I guess you missed my reply.
> > >
> > > its not in my mailer in this thread.. did your mailer break the
> > > thread again?
> > > (like oh so many people do making it impossible to follow
> > > threads). :)
> > 
> > 
> > Well I don't think so. Gmail works very fine with this kind of mail
> > thread. The title is still "Re: [E-devel] [PATCH] [Elementary]
> > Patch to fix elementary list with separator".
> > It should work.
> 
> thieps mail broke it. clients break thread by removing the
> In-Reply-To field in the header. this is the header that for the past
> what 15.. 20  years has been used by mail clients to figure out
> threads. it knows WHAT mail id this was in reply to... a mailer will
> assign a unique id with Message-ID when you send it, so mail clients
> can "trace" these id's and reply tos and do a thread correctly and
> repliably. thats how it can do multiple levels of nesting etc. too.
> 
> gmail GUESSES by the subject being the same with an Re: that it might
> be a thread. but it cant know exactly what you reply to like a proper
> nesting thread unless you use such mail id's.

Which might break when people change the subject, coz the thread has
veered off into other territory.

> bad mail clients are unsociable and break such threads by simply
> posting a whole new mail to the list with no context/reference what
> it is in reply to. it breaks other peoples ability to track the
> conversation properly even though for like 20 years clients have been
> playing nice. now they just don't bother and are rude and remove such
> threading info.

There are also people that try to have a conversation with the digest
emails, and thus end up making all their posts a new thread, coz those
not getting the digest don't know what to link it to.

-- 
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
--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Edje color/text_class_list bugs

[Davide Andreoli]

2013/2/18 Carsten Haitzler 

> On Mon, 11 Feb 2013 22:46:32 +0100 Davide Andreoli  >
> said:
>
> i fixed it. :)
>

cool ! thanks, I will test it this evening



>
> > Hi guys,
> > I think I found 2 bugs in edje (trunk):
> >
> > edje_color_class_list() and edje_text_class_list() always return
> nothing...
> >
> > see a super simple example at:
> > http://pastebin.com/8dAiaFzR
> >
> > looking at the code seems that the 2 functions implementation search in
> the
> > wrong hash,
> > but I'm not sure...
> >
> > can someone give a look please ?
> >
> > thanks
> >
> > davemds
> >
> --
> > Free Next-Gen Firewall Hardware Offer
> > Buy your Sophos next-gen firewall before the end March 2013
> > and get the hardware for free! Learn more.
> > http://p.sf.net/sfu/sophos-d2d-feb
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] EFL Snippet Sharing

[Leif Middelschulte]

Hello everyone,  

Every few days I come across some functionality that isn't usable 'straight 
forward' but isn't explicitly documented either. After asking on IRC I usually 
go back to read the library's C code, which sometimes is quite a bit time 
consuming.

Since I strongly believe that many problems and their respective solutions are 
reoccurring, I'd like to have some sort of searchable snippets for EFL usage.

I'm referring to short snippets, not to full fledged examples that could be 
added to examples/ or deserve a blog entry/whatever.

Let me give you an example:
Problem: Change an edje part's rel1 value via message using embryo
Straight forward solution I assumed:
set_state_val(…)
Real solution:
custom_state(…)
set_state_val(…)
set_state(…)

Now I'd go and create a snippet that contains only the few correct lines + 
comments and tag it with e.g.: "edje part geometry change rel1 embryo message"

I imagine a dedicated git repository (e.g. 'snippets') that contains tagged 
code snippets (first commit line) and a web interface to eventually 
add/edit/browse/search entries. Luckily we have phabricator, which already 
provides all of this :-) Now we'd just need to add such a repository.

What do you guys think?  

--  
Leif

--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Fwd: ecore: add Ecore_Coroutine.

[Tom Hacohen]

NOOO :)

--
Tom.
 Original Message 
Subject:ecore: add Ecore_Coroutine.
Date:   Mon, 18 Feb 2013 13:38:33 GMT
From:   Cedric BAIL 



ecore: add Ecore_Coroutine. That work clearly was possible thanks to
Leandro. If you want more information go to his blog :
http://tia.mat.br/posts/async_io_with_coroutines/ . The main difference
with his implementation is more portable and not thread safe. It does
not have a custom swapcontext (would make sense as we don't need to save
the sigcontext) so it will be less fast. If people are ready to
contribute asm patch for that purpose I will be happy to apply them. As
for portability this code should work on all architecture we already
support thanks to a nice hack with setjmp/longjmp borowed from
libcoroutine. We do use Fiber for Windows support, but as 1.8 is
completely borken in that regard, this is theorical work only. Thinks
left to do : - Eoify the API - Documentation - More tests - Add support
for coroutine in fd handler - Add coroutine support to ecore_thread api
- Write some example



--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] edbus

[Daniel Willmann]

Hello,

could someone with knowledge please take a look at method_close() in
src/bin/edbus/parser.c

It seems like the method->cb_name = strdup("NULL"); before free(method);
leaks memory. I know too little about where/how the global var method is
being used to decide here.


Regards,
Daniel


--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] edbus

[Jose Souza]

Hi Daniel

I don't see any leaks.
method->cb_name = strdup("NULL"); is because the method have no reply
annotation and this is only know after ""
The DBus_Method and all strings of they will be freed when
object_free()->inteface_free()->method_free() is called.

On Mon, Feb 18, 2013 at 10:53 AM, Daniel Willmann wrote:

> Hello,
>
> could someone with knowledge please take a look at method_close() in
> src/bin/edbus/parser.c
>
> It seems like the method->cb_name = strdup("NULL"); before free(method);
> leaks memory. I know too little about where/how the global var method is
> being used to decide here.
>
>
> Regards,
> Daniel
>
>
--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] SVN->Git Migration (was: (no subject))

[Bruno Dilly]

On Sat, Feb 16, 2013 at 4:42 AM, Jérôme Pinot  wrote:
> On 02/16/13 15:58, David Seikel wrote:
>> On Fri, 15 Feb 2013 11:56:06 -0200 Rafael Antognolli
>>  wrote:
>>
>> > Hi David,
>> >
>> > On Thu, Feb 14, 2013 at 9:12 AM, David Seikel 
>> > wrote:
>> > > On Thu, 14 Feb 2013 08:53:22 -0200 Bruno Dilly
>> > >  wrote:
>> > >
>> > >> On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann
>> > >>  wrote:
>> > >> > On 13/02/13 00:36, Bruno Dilly wrote:
>> > >> >> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann
>> > >> >>  wrote:
>> > >> >>>
>> > >> >>> Topic branches:
>> > >> >>> * In each repository every developer with commit access will be
>> > >> >>> able to push/update branches in their own namespace
>> > >> >>> (devs//*). These branches will allow non-fastforward
>> > >> >>> updates and no one should expect these to be stable.
>> > >> >>> * This is a testing ground for developers where new features
>> > >> >>> can be developed, debugged and shared with fellow developers.
>> > >> >>> Ideally any new feature would live in its own branch until it
>> > >> >>> matures and is merged into master.
>> > >> >>
>> > >> >> Hey Daniel,
>> > >> >>
>> > >> >> It's a nice proposal, but what about master branch permissions ?
>> > >> >> Every developer would be allowed to push stuff on there (with a
>> > >> >> flow similar to svn) ? Or we'll try to establish some kind of
>> > >> >> policy about it (maintainers, review, etc) ?
>> > >> >
>> > >> > As others have already pointed out there seems to be consensus
>> > >> > that we don't have enough manpower to work with an integrator
>> > >> > workflow (whether or not that's true I don't know).
>> > >>
>> > >> ok, I got it.
>> > >>
>> > >> >
>> > >> > What I want to achieve with the topic branches is that whoever
>> > >> > wants to can maintain an integrator-like workflow. You develop
>> > >> > your feature in a topic branch, then post a request for
>> > >> > review/review and test yourself and if everything looks good you
>> > >> > can merge into master.
>> > >> >
>> > >> > Speaking of merging...is there any preference on merge vs.
>> > >> > rebase?
>> > >> >
>> > >> > Lots of small merges can really pollute your history and I don't
>> > >> > really like them. For larger topic branches I think merging makes
>> > >> > sense.
>> > >>
>> > >> I agree with Tom here.
>> > >> I'm always trying to keep a linear history, focusing on rebases
>> > >> instead of merges.
>> > >> We've used this approach on Profusion projects for years and it
>> > >> worked fine so far.
>> > >>
>> > >> Maybe it will give you a little bit more work, you'll have to fix
>> > >> conflicts in the commits it happens instead of only once in a final
>> > >> merge commit, but it will be nicer to review or look
>> > >> for issues later, imo.
>> > >>
>> > >> Using the merge approach, in a project with so many commiters could
>> > >> lead us to a very confuse history.
>> > >
>> > > If the history is confused, then that's what it should show.  I
>> > > really don't like the idea of rewriting history just to make it
>> > > easier for some people.  Sometimes you just need to track down what
>> > > actually happened, not the convenient lie we tell ourselves is what
>> > > happened.
>> >
>> > I don't think those that a rebased branch history is a lie. Each
>> > commit will still have the original commit date (if the author did not
>> > change it). You can use that to know when the feature started to be
>> > developed.
>>
>> It is a lie, it's changing the history to say it was all done one after
>> the other, when in fact a major feature of distributed development was
>> used to branch then merge.  It was not done in a linear fashion, thus
>> making it be linear after the fact is not representing the truth.  Sure
>> SOME parts of the commit history are still the truth, but not all.
>>
>> > OK, you lose a way to track the parent commit for that feature branch,
>> > but on the other hand you earn something important here: the knowledge
>> > that the commits from that feature branch will apply correctly on top
>> > of the current state of the tree, without a magic merge commit fixing
>> > stuff later since some things on the tree are not exactly as they seem
>> > to be in the diff from this commit. The changes that appear in the
>> > diff from a given commit are exactly what that commit is doing.
>>
>> That's what I'm saying, loosing information to make things more
>> convenient.  I'd prefer to err on the side of not loosing information.
>> But then again, I'm a hoarder.  B-)
>>
>> > I know that this is not a poll, but I particularly prefer rebased
>> > branches/commits too.
>
> LWN has a neat article about the git rebase thing:
> http://lwn.net/Articles/328436/
>
> "Thou Shalt Not Rebase Trees With History Visible To Others"

Hey Jérôme,

Just to make things clear, nobody is suggesting to rebase master
branch (or any public branch).
Only devs/* will accept non-fastforward updates. But nobody else
should be based on these.

>
> --
>

Re: [E-devel] Build issue

[Bruno Dilly]

On Sun, Feb 17, 2013 at 1:06 AM, Cedric BAIL  wrote:
> On Sat, Feb 16, 2013 at 3:58 PM, Davide Andreoli  
> wrote:
>> 2013/2/16 Cedric BAIL 
>>> Our current build system is currently in a bad state and there was no
>>> improvements in the past week. So here is I think a TODO that everyone
>>> will agree with.
>>>
>>> - siginfo is not a portable API. There was a test and proper #if in
>>> 1.7, we should bring them back.
>>> - libmount is not recent enough for eeze 1.8 on debian. There was
>>> working code in 1.7, we should bring it back.
>>> - binary executed inside the build tree don't use the just build
>>> library, but the system one.
>>> - the profile (UI, server) are not there yet and should be added as
>>> latest discussion did reach consensus on that topic.
>>>
>>> I may have forgotten some issue here, so kindly remind them here. At
>>> least for the four top one, they will be blocker for the 1.8 release
>>> and need to be solved. I may go and fix the one I can when I have
>>> time, but any help will be appreciated.
>>>
>>
>> I suggest also to disable physics by default, as libbulett 2.8 is only is
>> super recent distro.
>
> That one can already be disabled by some configure flags, so I am
> happy with situation. It does encourage people to try and get bullet.
> That is useful as it is part of Edje and means we can have theme and
> wallpaper using physics effect. Nobody did try it yet, but some
> physics enabled wallpaper for e17 could be fun I think. Maybe a
> example would be needed here so people start to do some.

I've added examples using physics effects on examples/edje.
But only simple stuff, just covering the edje / embryo commands.
I'll see if I found some time to create a wallpaper soon, it's a very nice idea.

Regards

> --
> Cedric BAIL
>
> --
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now. http://goparallel.sourceforge.net/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



-- 
Bruno Dilly
Lead Developer
ProFUSION embedded systems
http://profusion.mobi

--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EFL/Evas PATCH] Introduce pixel_alpha_get() on engines

[Paulo C. A. Cavalcanti Jr]

Iván Briano  writes:

> Your patches seem to be coming with DOS newlines.
> Please fix your editor to avoid that.

Yeah, just fixed it. Thanks for pointing it out.

-- 
Paulo C. A. Cavalcanti Jr, Intel Open Source Technology Center
I speak only for myself.

--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EFL/Evas PATCH] Introduce pixel_alpha_get() on engines

[Paulo C. A. Cavalcanti Jr]

Hi Cedric,

Cedric BAIL  writes:

> Good for me, will be in svn^Wgit soon.

I just made a backported version of this patch. Feel free to push it out.
>From 92bbeb26b946a58a0889aa735d58ce72d48b66ec Mon Sep 17 00:00:00 2001
From: "Paulo C. A. Cavalcanti Jr" 
Date: Mon, 18 Feb 2013 12:45:40 -0300
Subject: [PATCH] evas/engines: Introduce pixel_alpha_get()

The _pixel_alpha_get() function used in evas_object_image_is_inside won't
work with engines other than software - since it relies on engine data
being *always* RGBA_Image * - which is wrong for OpenGL backend that uses
Evas_GL_Image * for "engine_data" pointer.

NOTE: Backported from upstream.

Signed-off-by: Paulo C. A. Cavalcanti Jr 
---
 src/lib/canvas/evas_object_image.c |  125 +++-
 src/lib/include/evas_private.h |2 +
 src/modules/engines/gl_x11/evas_engine.c   |   83 +
 src/modules/engines/software_generic/evas_engine.c |   90 +-
 4 files changed, 214 insertions(+), 86 deletions(-)

diff --git a/src/lib/canvas/evas_object_image.c b/src/lib/canvas/evas_object_image.c
index aeabd20..14556a2 100644
--- a/src/lib/canvas/evas_object_image.c
+++ b/src/lib/canvas/evas_object_image.c
@@ -3631,83 +3631,13 @@ evas_object_image_was_opaque(Evas_Object *obj)
return 1;
 }
 
-static inline Eina_Bool
-_pixel_alpha_get(RGBA_Image *im, int x, int y, DATA8 *alpha,
- int src_region_x, int src_region_y, int src_region_w, int src_region_h,
- int dst_region_x, int dst_region_y, int dst_region_w, int dst_region_h)
-{
-   int px, py, dx, dy, sx, sy, src_w, src_h;
-   double scale_w, scale_h;
-
-   if ((dst_region_x > x) || (x >= (dst_region_x + dst_region_w)) ||
-   (dst_region_y > y) || (y >= (dst_region_y + dst_region_h)))
- {
-*alpha = 0;
-return EINA_FALSE;
- }
-
-   src_w = im->cache_entry.w;
-   src_h = im->cache_entry.h;
-   if ((src_w == 0) || (src_h == 0))
- {
-*alpha = 0;
-return EINA_TRUE;
- }
-
-   EINA_SAFETY_ON_TRUE_GOTO(src_region_x < 0, error_oob);
-   EINA_SAFETY_ON_TRUE_GOTO(src_region_y < 0, error_oob);
-   EINA_SAFETY_ON_TRUE_GOTO(src_region_x + src_region_w > src_w, error_oob);
-   EINA_SAFETY_ON_TRUE_GOTO(src_region_y + src_region_h > src_h, error_oob);
-
-   scale_w = (double)dst_region_w / (double)src_region_w;
-   scale_h = (double)dst_region_h / (double)src_region_h;
-
-   /* point at destination */
-   dx = x - dst_region_x;
-   dy = y - dst_region_y;
-
-   /* point at source */
-   sx = dx / scale_w;
-   sy = dy / scale_h;
-
-   /* pixel point (translated) */
-   px = src_region_x + sx;
-   py = src_region_y + sy;
-   EINA_SAFETY_ON_TRUE_GOTO(px >= src_w, error_oob);
-   EINA_SAFETY_ON_TRUE_GOTO(py >= src_h, error_oob);
-
-   switch (im->cache_entry.space)
- {
- case EVAS_COLORSPACE_ARGB:
-   {
-  DATA32 *pixel = im->image.data;
-  pixel += ((py * src_w) + px);
-  *alpha = ((*pixel) >> 24) & 0xff;
-   }
-   break;
-
- default:
-ERR("Colorspace %d not supported.", im->cache_entry.space);
-*alpha = 0;
- }
-
-   return EINA_TRUE;
-
- error_oob:
-   ERR("Invalid region src=(%d, %d, %d, %d), dst=(%d, %d, %d, %d), image=%dx%d",
-   src_region_x, src_region_y, src_region_w, src_region_h,
-   dst_region_x, dst_region_y, dst_region_w, dst_region_h,
-   src_w, src_h);
-   *alpha = 0;
-   return EINA_TRUE;
-}
-
 static int
 evas_object_image_is_inside(Evas_Object *obj, Evas_Coord px, Evas_Coord py)
 {
Evas_Object_Image *o;
int imagew, imageh, uvw, uvh;
void *pixels;
+   Evas_Func *eng = obj->layer->evas->engine.func;
int is_inside = 0;
 
/* the following code is similar to evas_object_image_render(), but doesn't
@@ -3778,7 +3708,7 @@ evas_object_image_is_inside(Evas_Object *obj, Evas_Coord px, Evas_Coord py)
   }
 else
   {
- RGBA_Image *im;
+ void *im;
  DATA32 *data = NULL;
  int err = 0;
 
@@ -3786,7 +3716,8 @@ evas_object_image_is_inside(Evas_Object *obj, Evas_Coord px, Evas_Coord py)
(obj->layer->evas->engine.data.output, pixels, 0, &data, &err);
  if ((!im) || (!data) || (err))
{
-  ERR("Couldn't get image pixels RGBA_Image %p: im=%p, data=%p, err=%d", pixels, im, data, err);
+  ERR("Couldn't get image pixels %p: im=%p, data=%p, err=%d",
+  pixels, im, data, err);
   goto end;
}
 
@@ -3834,7 +3765,13 @@ evas_object_image_is_inside(Evas_Object *obj, Evas_Coord px, Evas_Coord py)
  */
   {
  DATA8 alpha = 0;
- if (_pixel_alpha_get(pixels, px, py, &alpha, 0, 0, imagew, imageh, obj->cur.geometry.x + ix, obj->cur.geometry.y + iy, iw, ih))
+
+ 

Re: [E-devel] E SVN: sachiel IN branches/evas-1.7/src: lib/canvas lib/include modules/engines/gl_x11 modules/engines/software_generic

[Paulo Alcantara]

Thanks! And again, sorry for the DOS newlines. I'll blame Gnus for that.

On Mon, Feb 18, 2013 at 1:18 PM, Enlightenment SVN
 wrote:
> Log:
> evas/engines: Introduce pixel_alpha_get()
>
>   The _pixel_alpha_get() function used in evas_object_image_is_inside won't
>   work with engines other than software - since it relies on engine data
>   being *always* RGBA_Image * - which is wrong for OpenGL backend that uses
>   Evas_GL_Image * for "engine_data" pointer.
>
>   NOTE: Backported from upstream.
>
>   Signed-off-by: Paulo C. A. Cavalcanti Jr 
>
>   Patch by: "Paulo C. A. Cavalcanti Jr" 
>
>
>
> Author:   sachiel
> Date: 2013-02-18 08:18:17 -0800 (Mon, 18 Feb 2013)
> New Revision: 84067
> Trac: http://trac.enlightenment.org/e/changeset/84067
>
> Modified:
>   branches/evas-1.7/src/lib/canvas/evas_object_image.c 
> branches/evas-1.7/src/lib/include/evas_private.h 
> branches/evas-1.7/src/modules/engines/gl_x11/evas_engine.c 
> branches/evas-1.7/src/modules/engines/software_generic/evas_engine.c
>
> Modified: branches/evas-1.7/src/lib/canvas/evas_object_image.c
> ===
> --- branches/evas-1.7/src/lib/canvas/evas_object_image.c2013-02-18 
> 16:07:30 UTC (rev 84066)
> +++ branches/evas-1.7/src/lib/canvas/evas_object_image.c2013-02-18 
> 16:18:17 UTC (rev 84067)
> @@ -3631,83 +3631,13 @@
> return 1;
>  }
>
> -static inline Eina_Bool
> -_pixel_alpha_get(RGBA_Image *im, int x, int y, DATA8 *alpha,
> - int src_region_x, int src_region_y, int src_region_w, int 
> src_region_h,
> - int dst_region_x, int dst_region_y, int dst_region_w, int 
> dst_region_h)
> -{
> -   int px, py, dx, dy, sx, sy, src_w, src_h;
> -   double scale_w, scale_h;
> -
> -   if ((dst_region_x > x) || (x >= (dst_region_x + dst_region_w)) ||
> -   (dst_region_y > y) || (y >= (dst_region_y + dst_region_h)))
> - {
> -*alpha = 0;
> -return EINA_FALSE;
> - }
> -
> -   src_w = im->cache_entry.w;
> -   src_h = im->cache_entry.h;
> -   if ((src_w == 0) || (src_h == 0))
> - {
> -*alpha = 0;
> -return EINA_TRUE;
> - }
> -
> -   EINA_SAFETY_ON_TRUE_GOTO(src_region_x < 0, error_oob);
> -   EINA_SAFETY_ON_TRUE_GOTO(src_region_y < 0, error_oob);
> -   EINA_SAFETY_ON_TRUE_GOTO(src_region_x + src_region_w > src_w, error_oob);
> -   EINA_SAFETY_ON_TRUE_GOTO(src_region_y + src_region_h > src_h, error_oob);
> -
> -   scale_w = (double)dst_region_w / (double)src_region_w;
> -   scale_h = (double)dst_region_h / (double)src_region_h;
> -
> -   /* point at destination */
> -   dx = x - dst_region_x;
> -   dy = y - dst_region_y;
> -
> -   /* point at source */
> -   sx = dx / scale_w;
> -   sy = dy / scale_h;
> -
> -   /* pixel point (translated) */
> -   px = src_region_x + sx;
> -   py = src_region_y + sy;
> -   EINA_SAFETY_ON_TRUE_GOTO(px >= src_w, error_oob);
> -   EINA_SAFETY_ON_TRUE_GOTO(py >= src_h, error_oob);
> -
> -   switch (im->cache_entry.space)
> - {
> - case EVAS_COLORSPACE_ARGB:
> -   {
> -  DATA32 *pixel = im->image.data;
> -  pixel += ((py * src_w) + px);
> -  *alpha = ((*pixel) >> 24) & 0xff;
> -   }
> -   break;
> -
> - default:
> -ERR("Colorspace %d not supported.", im->cache_entry.space);
> -*alpha = 0;
> - }
> -
> -   return EINA_TRUE;
> -
> - error_oob:
> -   ERR("Invalid region src=(%d, %d, %d, %d), dst=(%d, %d, %d, %d), 
> image=%dx%d",
> -   src_region_x, src_region_y, src_region_w, src_region_h,
> -   dst_region_x, dst_region_y, dst_region_w, dst_region_h,
> -   src_w, src_h);
> -   *alpha = 0;
> -   return EINA_TRUE;
> -}
> -
>  static int
>  evas_object_image_is_inside(Evas_Object *obj, Evas_Coord px, Evas_Coord py)
>  {
> Evas_Object_Image *o;
> int imagew, imageh, uvw, uvh;
> void *pixels;
> +   Evas_Func *eng = obj->layer->evas->engine.func;
> int is_inside = 0;
>
> /* the following code is similar to evas_object_image_render(), but 
> doesn't
> @@ -3778,7 +3708,7 @@
>}
>  else
>{
> - RGBA_Image *im;
> + void *im;
>   DATA32 *data = NULL;
>   int err = 0;
>
> @@ -3786,7 +3716,8 @@
> (obj->layer->evas->engine.data.output, pixels, 0, &data, 
> &err);
>   if ((!im) || (!data) || (err))
> {
> -  ERR("Couldn't get image pixels RGBA_Image %p: im=%p, 
> data=%p, err=%d", pixels, im, data, err);
> +  ERR("Couldn't get image pixels %p: im=%p, data=%p, err=%d",
> +  pixels, im, data, err);
>goto end;
> }
>
> @@ -3834,7 +3765,13 @@
>   */
>{
>   DATA8 alpha = 0;
> - if (_pixel_alpha_get(pixels, px, py, 
> &alpha, 0, 0, imagew, image

Re: [E-devel] edbus

[Daniel Willmann]

On 18/02/13 14:35, Jose Souza wrote:
> Hi Daniel
> 
> I don't see any leaks.
> method->cb_name = strdup("NULL"); is because the method have no reply
> annotation and this is only know after ""
> The DBus_Method and all strings of they will be freed when
> object_free()->inteface_free()->method_free() is called.

Method is set to NULL at the end of method_close(), but I guess there
must be some other reference to that pointer that still exists somewhere?

Otherwise you're doing

method->cb_name = strdup("NULL");
method = NULL;

> On Mon, Feb 18, 2013 at 10:53 AM, Daniel Willmann
> wrote:
> 
>> Hello,
>>
>> could someone with knowledge please take a look at method_close() in
>> src/bin/edbus/parser.c
>>
>> It seems like the method->cb_name = strdup("NULL"); before free(method);
>> leaks memory. I know too little about where/how the global var method is
>> being used to decide here.


Daniel

--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EFL/Evas PATCH] Introduce pixel_alpha_get() on engines

[Iván Briano]

On Mon, Feb 18, 2013 at 12:57 PM, Paulo C. A. Cavalcanti Jr
 wrote:
> Hi Cedric,
>
> Cedric BAIL  writes:
>
>> Good for me, will be in svn^Wgit soon.
>
> I just made a backported version of this patch. Feel free to push it out.

In it went.

>
> --
> Paulo C. A. Cavalcanti Jr, Intel Open Source Technology Center
> I speak only for myself.
>
> --
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now. http://goparallel.sourceforge.net/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: sachiel IN branches/evas-1.7/src: lib/canvas lib/include modules/engines/gl_x11 modules/engines/software_generic

[Michael Blumenkrantz]

On Mon, 18 Feb 2013 13:20:02 -0300
Paulo Alcantara  wrote:

> Thanks! And again, sorry for the DOS newlines. I'll blame Gnus for that.
> 
> On Mon, Feb 18, 2013 at 1:18 PM, Enlightenment SVN
>  wrote:
> > Log:
> > evas/engines: Introduce pixel_alpha_get()
> >
> >   The _pixel_alpha_get() function used in evas_object_image_is_inside won't
> >   work with engines other than software - since it relies on engine data
> >   being *always* RGBA_Image * - which is wrong for OpenGL backend that uses
> >   Evas_GL_Image * for "engine_data" pointer.
> >
> >   NOTE: Backported from upstream.
> >
> >   Signed-off-by: Paulo C. A. Cavalcanti Jr 
> >
> >   Patch by: "Paulo C. A. Cavalcanti Jr" 
> >
> >
> >
> > Author:   sachiel
> > Date: 2013-02-18 08:18:17 -0800 (Mon, 18 Feb 2013)
> > New Revision: 84067
> > Trac: http://trac.enlightenment.org/e/changeset/84067
> >
> > Modified:
> >   branches/evas-1.7/src/lib/canvas/evas_object_image.c 
> > branches/evas-1.7/src/lib/include/evas_private.h 
> > branches/evas-1.7/src/modules/engines/gl_x11/evas_engine.c 
> > branches/evas-1.7/src/modules/engines/software_generic/evas_engine.c

it's okay, notepad is the preferred editor at samsung too

--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] edbus

[Jose Souza]

In method_new() the method is append to inlist of methods in interface.

On Mon, Feb 18, 2013 at 1:21 PM, Daniel Willmann wrote:

> On 18/02/13 14:35, Jose Souza wrote:
> > Hi Daniel
> >
> > I don't see any leaks.
> > method->cb_name = strdup("NULL"); is because the method have no reply
> > annotation and this is only know after ""
> > The DBus_Method and all strings of they will be freed when
> > object_free()->inteface_free()->method_free() is called.
>
> Method is set to NULL at the end of method_close(), but I guess there
> must be some other reference to that pointer that still exists somewhere?
>
> Otherwise you're doing
>
> method->cb_name = strdup("NULL");
> method = NULL;
>
> > On Mon, Feb 18, 2013 at 10:53 AM, Daniel Willmann
> > wrote:
> >
> >> Hello,
> >>
> >> could someone with knowledge please take a look at method_close() in
> >> src/bin/edbus/parser.c
> >>
> >> It seems like the method->cb_name = strdup("NULL"); before free(method);
> >> leaks memory. I know too little about where/how the global var method is
> >> being used to decide here.
>
>
> Daniel
>
--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] User-generated "wild" git repositories

[Daniel Willmann]

Hello,

this is a heads up that user-controlled repositories are now visible
through cgit (as was the intention all along).

So remove all embarrassing stuff there. :-)


For everyone who didn't know about this - you can create new
repositories under your own namespace just by cloning it. I would do:

git clone ssh://g...@git.enlightenment.org/devs/asdfuser/foo.git

Which will create a new empty repository for me to start a new project,
etc. These projects are readable for the public through the git-daemon
and cgit and currently every developer can push to all existing repos
(so be nice).

You can delete a repository you created by executing the trash command
through gitolite like this:
$ ssh g...@git.enlightenment.org trash devs/asdfuser/test.git
devs/asdfuser/test moved to trashcan.  Please run the 'help' adc for
more info.

To list the currently deleted repos type:
$ ssh g...@git.enlightenment.org list-trash
devs/asdfuser/test/2013-02-18_09:48:08

And to restore a repository again:
$ ssh g...@git.enlightenment.org restore
devs/asdfuser/test/2013-02-18_09:48:08


Regards,
Daniel Willmann

--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] User-generated "wild" git repositories

[Daniel Willmann]

On 18/02/13 17:52, Daniel Willmann wrote:
> Hello,
> 
> this is a heads up that user-controlled repositories are now visible
> through cgit (as was the intention all along).
> 
> So remove all embarrassing stuff there. :-)
> 
> 
> For everyone who didn't know about this - you can create new
> repositories under your own namespace just by cloning it. I would do:
> 
> git clone ssh://g...@git.enlightenment.org/devs/asdfuser/foo.git
> 
> Which will create a new empty repository for me to start a new project,
> etc. These projects are readable for the public through the git-daemon
> and cgit and currently every developer can push to all existing repos
> (so be nice).

To change the description of this repository so cgit shows something
else than "Unnamed repository; edit this file 'description' to name the
repository." you can run the setdesc command:

echo "My description" | ssh g...@git.enlightenment.org setdesc
devs/asdfuser/test.git


Regards,
Daniel

--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] SVN->Git Migration

[Martin Jansa]

On Mon, Feb 18, 2013 at 09:36:50AM +, Stefan Schmidt wrote:
> Hello.
> 
> On 18/02/13 09:21, Tom Hacohen wrote:
> > On 18/02/13 04:02, Daniel Juyung Seo wrote:
> >> And it'll be great if the title includes the first line of commit
> > message.
> >> That should be way more useful.
> >> Thanks.
> >
> > Correct me if I'm wrong, but I'm starting to think you guys would like
> > to see the whole diff in the title.
> 
> Come on. Take a step back and look at the commit email subject line as 
> we have it right now:
> 
> [EGIT] [core/efl] branch master updated. 
> 04e660c5c76fa9168be08de1f979a1684c464154
> 
> [EGIT] Might be needed for people that can or want not filter on message 
> headers.
> 
> [core/efl] Gives the repo. Useful.
> 
> branch master updated: I argued before that commit mails should only be 
> send for the master branch. Everything else is only interesting for a 
> small group of people and they will pull and look at the specific 
> branches on their own.
> 
> git hash: Not useful in the title I would argue. Gives you zero 
> informations about what was changed. Needed in the body for sure, but 
> not in the subject.

OE has IMHO good setup for git commits, and it should be easy to get
their git hook. Messages look like this:

From: g...@git.openembedded.org 

   
Subject: [oe-commits] Martin Jansa : ca-certificates: upgrade to 20130119   

  


  
Module: meta-openembedded.git   

  
Branch: master  

  
Commit: af0a0dde191acb5725073e30a8a0b42d819233c6

  
URL:
http://git.openembedded.org/?p=meta-openembedded.git&a=commit;h=af0a0dde191acb5725073e30a8a0b42d819233c6
  


  
Author: Martin Jansa

  
Date:   Mon Feb 11 20:23:51 2013 +  

  


  
ca-certificates: upgrade to 20130119

  


  
* old archive is no longer on upstream URL  

  


  
Signed-off-by: Martin Jansa 

  

---

whole patch here

---

With this format it's easy to filter emails to different mail foder for 
different
branches or modules.

Cheers,

> 
> I would propose:
> 
> [EGIT] [core/efl] First line of commit message.
> 
> The body does then have the full commit message, the hash as well as a 
> shortlog before the complete diff comes in.
> 
> And yes that means one commit should result in one mail.
> 
> regards
> Stefan Schmidt
> 
> --
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
> is your hub for all things parallel software development, from weekly thought 
> leadership blogs to news, videos, case studies, tutorials, tech docs, 
> whitepapers, evaluation guides, and opinion stories. Check out the most 
> recent posts - join the conversation now. http://goparallel.sour

[E-devel] elementary and enlightenment are moving on Friday (22.02.2013)

[Daniel Willmann]

Hello,

this Friday (22/02/2013) we will be moving both elementary and
enlightenment to Git.

The schedule is the same a last week:

09:00 UTC: Final warning mail. You should stop committing to
/trunk/{e,elementary} in SVN
10:00 UTC: Raster will lock the directories so nobody accidentally
commits there. When that is done we will update the Git repository for
and verify that everything is working.

??:00 UTC: Access will be restored to Git and I'll send an announcement
that the migration is done.

The new web frontend is here (phabricator is there as well, but requires
login):
https://git.enlightenment.org/core/elementary.git
https://git.enlightenment.org/core/enlightenment.git

Read-only git access:
git clone git://git.enlightenment.org/core/elementary.git
git clone git://git.enlightenment.org/core/enlightenment.git

Or for developers (not available at the moment):
git clone ssh://g...@git.enlightenment.org/core/elementary.git
git clone ssh://g...@git.enlightenment.org/core/enlightenment.git


Regards,
Daniel

--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL Snippet Sharing

[Davide Andreoli]

2013/2/18 Leif Middelschulte 

> Hello everyone,
>
> Every few days I come across some functionality that isn't usable
> 'straight forward' but isn't explicitly documented either. After asking on
> IRC I usually go back to read the library's C code, which sometimes is
> quite a bit time consuming.
>
> Since I strongly believe that many problems and their respective solutions
> are reoccurring, I'd like to have some sort of searchable snippets for EFL
> usage.
>
> I'm referring to short snippets, not to full fledged examples that could
> be added to examples/ or deserve a blog entry/whatever.
>
> Let me give you an example:
> Problem: Change an edje part's rel1 value via message using embryo
> Straight forward solution I assumed:
> set_state_val(…)
> Real solution:
> custom_state(…)
> set_state_val(…)
> set_state(…)
>

exactly this is explained in the example:
efl/src/examples/edje/embryo_custom_state.edc


>
> Now I'd go and create a snippet that contains only the few correct lines +
> comments and tag it with e.g.: "edje part geometry change rel1 embryo
> message"
>
> I imagine a dedicated git repository (e.g. 'snippets') that contains
> tagged code snippets (first commit line) and a web interface to eventually
> add/edit/browse/search entries. Luckily we have phabricator, which already
> provides all of this :-) Now we'd just need to add such a repository.
>
> What do you guys think?
>

I don't think a new place to put example is a good idea, will make the
search of resources
more difficult. We have example/test/snippets too much sparse around: in
sources, in the wiki, in examples, in tests... I think we need a sort of
"contentrator" for all that info around.
Maybe a well done wiki page can be enough, I'm thinking of a sort of "big
index" of
resources grouped by libs.



>
> --
> Leif
>
>
> --
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly
> thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now.
> http://goparallel.sourceforge.net/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL Snippet Sharing

[Leif Middelschulte]

Am Montag, 18. Februar 2013 um 20:34 schrieb Davide Andreoli:
> 2013/2/18 Leif Middelschulte  (mailto:leif.middelschu...@gmail.com)>
>  
> > Hello everyone,
> >  
> > Every few days I come across some functionality that isn't usable
> > 'straight forward' but isn't explicitly documented either. After asking on
> > IRC I usually go back to read the library's C code, which sometimes is
> > quite a bit time consuming.
> >  
> > Since I strongly believe that many problems and their respective solutions
> > are reoccurring, I'd like to have some sort of searchable snippets for EFL
> > usage.
> >  
> > I'm referring to short snippets, not to full fledged examples that could
> > be added to examples/ or deserve a blog entry/whatever.
> >  
> > Let me give you an example:
> > Problem: Change an edje part's rel1 value via message using embryo
> > Straight forward solution I assumed:
> > set_state_val(…)
> > Real solution:
> > custom_state(…)
> > set_state_val(…)
> > set_state(…)
> >  
>  
>  
> exactly this is explained in the example:
> efl/src/examples/edje/embryo_custom_state.edc
>  
>  

I didn't want a custom state. I wanted to modify the current one. So this is - 
imo - not straight forward! Nevertheless I found an example that showed it.
> >  
> > Now I'd go and create a snippet that contains only the few correct lines +
> > comments and tag it with e.g.: "edje part geometry change rel1 embryo
> > message"
> >  
> > I imagine a dedicated git repository (e.g. 'snippets') that contains
> > tagged code snippets (first commit line) and a web interface to eventually
> > add/edit/browse/search entries. Luckily we have phabricator, which already
> > provides all of this :-) Now we'd just need to add such a repository.
> >  
> > What do you guys think?
>  
> I don't think a new place to put example is a good idea, will make the
> search of resources more difficult. We have example/test/snippets too much 
> sparse around: in sources, in the wiki, in examples, in tests... I think we 
> need a sort of
> "contentrator" for all that info around.

As I wrote it's not about full examples, just snippets!
Are you familiar with gists? (see http://gist.github.com)
I don't have the time to write out entire examples, but have the time to 
copy/paste a few lines I just coded/figured out and add some comments to them.
> Maybe a well done wiki page can be enough, I'm thinking of a sort of "big
> index" of resources grouped by libs.

If we'd use a git repository you could use tools of your choice (e.g. grep) to 
search the given snippets for matching tags (either we embed them into the 
commit message or into the files).
> >  
> > --
> > Leif
> >  
> >  
> > --
> > The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> > is your hub for all things parallel software development, from weekly
> > thought
> > leadership blogs to news, videos, case studies, tutorials, tech docs,
> > whitepapers, evaluation guides, and opinion stories. Check out the most
> > recent posts - join the conversation now.
> > http://goparallel.sourceforge.net/
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net 
> > (mailto:enlightenment-devel@lists.sourceforge.net)
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >  
>  
> --
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,  
> is your hub for all things parallel software development, from weekly thought 
>  
> leadership blogs to news, videos, case studies, tutorials, tech docs,  
> whitepapers, evaluation guides, and opinion stories. Check out the most  
> recent posts - join the conversation now. http://goparallel.sourceforge.net/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net 
> (mailto:enlightenment-devel@lists.sourceforge.net)
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Edje color/text_class_list bugs

[Davide Andreoli]

2013/2/18 Carsten Haitzler 

> On Mon, 11 Feb 2013 22:46:32 +0100 Davide Andreoli  >
> said:
>
> i fixed it. :)
>

Yes fixed, but spotted an api-design problem:
color_class_list return a list of string to free()ed
while text_class_list return a stringshared pointer that need to be
stringshare_del()

...also the doc is wrong for the second function
what to do ? just adjust the docs?



>
> > Hi guys,
> > I think I found 2 bugs in edje (trunk):
> >
> > edje_color_class_list() and edje_text_class_list() always return
> nothing...
> >
> > see a super simple example at:
> > http://pastebin.com/8dAiaFzR
> >
> > looking at the code seems that the 2 functions implementation search in
> the
> > wrong hash,
> > but I'm not sure...
> >
> > can someone give a look please ?
> >
> > thanks
> >
> > davemds
> >
> --
> > Free Next-Gen Firewall Hardware Offer
> > Buy your Sophos next-gen firewall before the end March 2013
> > and get the hardware for free! Learn more.
> > http://p.sf.net/sfu/sophos-d2d-feb
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] User-generated "wild" git repositories

[Bertrand Jacquin]

> You can delete a repository you created by executing the trash 
> command
> through gitolite like this:
> $ ssh g...@git.enlightenment.org trash devs/asdfuser/test.git
> devs/asdfuser/test moved to trashcan.  Please run the 'help' adc for
> more info.
>
> To list the currently deleted repos type:
> $ ssh g...@git.enlightenment.org list-trash
> devs/asdfuser/test/2013-02-18_09:48:08
>
> And to restore a repository again:
> $ ssh g...@git.enlightenment.org restore
> devs/asdfuser/test/2013-02-18_09:48:08

Also, if you are annoying with messages like :

   "PTY allocation request failed on channel 0"

You need to add the -T option to ssh :

$ ssh -T g...@git.enlightenment.org list-trash

-- 
Beber

--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Platform specific engine new function

[Andreas Volz]

Hello,

while writing a new Android engine I don't see how you set the platform
specific engine new function. e.g. for FB in ecore_evas.h

EAPI Ecore_Evas *
ecore_evas_fb_new(const char *disp_name, int rotation, int w, int h)

In this case there're only basic types. But for the case that I have a
special platform dependant drawing handle how would I do this?

Would you suggest to define a void* and simply cast it in the engine
itself? Is this the desired way at this point?

regards
Andreas

-- 
Technical Blog 

--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL Snippet Sharing

[The Rasterman]

On Mon, 18 Feb 2013 20:53:42 +0100 Leif Middelschulte
 said:

> Am Montag, 18. Februar 2013 um 20:34 schrieb Davide Andreoli:
> > 2013/2/18 Leif Middelschulte  > (mailto:leif.middelschu...@gmail.com)> 
> > > Hello everyone,
> > >  
> > > Every few days I come across some functionality that isn't usable
> > > 'straight forward' but isn't explicitly documented either. After asking on
> > > IRC I usually go back to read the library's C code, which sometimes is
> > > quite a bit time consuming.
> > >  
> > > Since I strongly believe that many problems and their respective solutions
> > > are reoccurring, I'd like to have some sort of searchable snippets for EFL
> > > usage.
> > >  
> > > I'm referring to short snippets, not to full fledged examples that could
> > > be added to examples/ or deserve a blog entry/whatever.
> > >  
> > > Let me give you an example:
> > > Problem: Change an edje part's rel1 value via message using embryo
> > > Straight forward solution I assumed:
> > > set_state_val(…)
> > > Real solution:
> > > custom_state(…)
> > > set_state_val(…)
> > > set_state(…)
> > >  
> >  
> >  
> > exactly this is explained in the example:
> > efl/src/examples/edje/embryo_custom_state.edc
> >  
> >  
> 
> I didn't want a custom state. I wanted to modify the current one. So this is
> - imo - not straight forward! Nevertheless I found an example that showed it.

you can't modify a state from embryo without making a custom state. you MAKE a
custom state FROM an existing state...

> > > Now I'd go and create a snippet that contains only the few correct lines +
> > > comments and tag it with e.g.: "edje part geometry change rel1 embryo
> > > message"
> > >  
> > > I imagine a dedicated git repository (e.g. 'snippets') that contains
> > > tagged code snippets (first commit line) and a web interface to eventually
> > > add/edit/browse/search entries. Luckily we have phabricator, which already
> > > provides all of this :-) Now we'd just need to add such a repository.
> > >  
> > > What do you guys think?
> >  
> > I don't think a new place to put example is a good idea, will make the
> > search of resources more difficult. We have example/test/snippets too much
> > sparse around: in sources, in the wiki, in examples, in tests... I think we
> > need a sort of "contentrator" for all that info around.
> 
> As I wrote it's not about full examples, just snippets!
> Are you familiar with gists? (see http://gist.github.com)
> I don't have the time to write out entire examples, but have the time to
> copy/paste a few lines I just coded/figured out and add some comments to them.
> > Maybe a well done wiki page can be enough, I'm thinking of a sort of "big
> > index" of resources grouped by libs.
> 
> If we'd use a git repository you could use tools of your choice (e.g. grep)
> to search the given snippets for matching tags (either we embed them into the
> commit message or into the files).
> > >  
> > > --
> > > Leif
> > >  
> > >  
> > > --
> > > The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> > > is your hub for all things parallel software development, from weekly
> > > thought
> > > leadership blogs to news, videos, case studies, tutorials, tech docs,
> > > whitepapers, evaluation guides, and opinion stories. Check out the most
> > > recent posts - join the conversation now.
> > > http://goparallel.sourceforge.net/
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > (mailto:enlightenment-devel@lists.sourceforge.net)
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel 
> >  
> > --
> > The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,  
> > is your hub for all things parallel software development, from weekly
> > thought leadership blogs to news, videos, case studies, tutorials, tech
> > docs, whitepapers, evaluation guides, and opinion stories. Check out the
> > most recent posts - join the conversation now.
> > http://goparallel.sourceforge.net/
> > ___ enlightenment-devel mailing
> > list enlightenment-devel@lists.sourceforge.net
> > (mailto:enlightenment-devel@lists.sourceforge.net)
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 
> 
> --
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
> is your hub for all things parallel software development, from weekly thought 
> leadership blogs to news, videos, case studies, tutorials, tech docs, 
> whitepapers, evaluation guides, and opinion stories. Check out the most 
> recent posts - join the conversation now. http://goparallel.sourceforge.net/
> 

Re: [E-devel] Edje color/text_class_list bugs

[The Rasterman]

On Mon, 18 Feb 2013 21:41:06 +0100 Davide Andreoli 
said:

> 2013/2/18 Carsten Haitzler 
> 
> > On Mon, 11 Feb 2013 22:46:32 +0100 Davide Andreoli  > >
> > said:
> >
> > i fixed it. :)
> >
> 
> Yes fixed, but spotted an api-design problem:
> color_class_list return a list of string to free()ed
> while text_class_list return a stringshared pointer that need to be
> stringshare_del()
> 
> ...also the doc is wrong for the second function
> what to do ? just adjust the docs?

yeah - this is i guess an api oddity... but reading Edje.h - it's correct. the
color class list is strduped and needs free()ing and the text class list is
stringshared and needs stringshare_del(). we can't change this at this stage
without an api/abi break... and docs are right:

 * @return A list of color class names (strings). These strings and
 * the list must be free()'d by the caller.

 * @return A list of text class names (strings). These strings are
 * stringshares and the list must be free()'d by the caller.

well it DOES say the strings are stringshares... so thus the logical call is
stirnghsare_del and the list freed with eina_list_free() for instance. docs are
not wrong - they are vague though.

> > > Hi guys,
> > > I think I found 2 bugs in edje (trunk):
> > >
> > > edje_color_class_list() and edje_text_class_list() always return
> > nothing...
> > >
> > > see a super simple example at:
> > > http://pastebin.com/8dAiaFzR
> > >
> > > looking at the code seems that the 2 functions implementation search in
> > the
> > > wrong hash,
> > > but I'm not sure...
> > >
> > > can someone give a look please ?
> > >
> > > thanks
> > >
> > > davemds
> > >
> > --
> > > Free Next-Gen Firewall Hardware Offer
> > > Buy your Sophos next-gen firewall before the end March 2013
> > > and get the hardware for free! Learn more.
> > > http://p.sf.net/sfu/sophos-d2d-feb
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >
> >
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am" --
> > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> >
> >


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


--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL Snippet Sharing

[Leif Middelschulte]

 Am Dienstag, 19. Februar 2013 um 00:50 schrieb Carsten Haitzler:

On Mon, 18 Feb 2013 20:53:42 +0100 Leif Middelschulte
 said:

Am Montag, 18. Februar 2013 um 20:34 schrieb Davide Andreoli:

2013/2/18 Leif Middelschulte mailto:leif.middelschu...@gmail.com )>

Hello everyone,
Every few days I come across some functionality that isn't usable
'straight forward' but isn't explicitly documented either. After asking on
IRC I usually go back to read the library's C code, which sometimes is
quite a bit time consuming.
Since I strongly believe that many problems and their respective solutions
are reoccurring, I'd like to have some sort of searchable snippets for EFL
usage.
I'm referring to short snippets, not to full fledged examples that could
be added to examples/ or deserve a blog entry/whatever.
Let me give you an example:
Problem: Change an edje part's rel1 value via message using embryo
Straight forward solution I assumed:
set_state_val(…)
Real solution:
custom_state(…)
set_state_val(…)
set_state(…)

 exactly this is explained in the example:
efl/src/examples/edje/embryo_custom_state.edc


I didn't want a custom state. I wanted to modify the current one. So this is
- imo - not straight forward! Nevertheless I found an example that showed
it.


you can't modify a state from embryo without making a custom state. you
MAKE a
custom state FROM an existing state...

Herrgott nochmal, it was just an example for a snippet ;-) Please stop
commenting about this particular example and think about other pieces of
code (if necessary)/the idea in general instead!

An examplary snippet _could_ look like:

embryo_part_modify_rel.edc:

// TAGS: edje embryo message part modify resize rel1 rel2

script {
public message(Msg_Type:type, id, ...) {
new Float:rel_val;
rel_val = getfarg(2);
custom_state(PART:"some_part", "default", 0.0); // We need
to create a custom state, since we can't modify a preexisting one
set_state_val(PART:"some_part", STATE_REL1, 0.0, rel_val);
// Modify the state we can actually modify
set_state(PART:"some_part", "custom", 0.0); // Set part's
state the the customized one
}

}

--
Leif


Now I'd go and create a snippet that contains only the few correct lines +
comments and tag it with e.g.: "edje part geometry change rel1 embryo
message"
I imagine a dedicated git repository (e.g. 'snippets') that contains
tagged code snippets (first commit line) and a web interface to eventually
add/edit/browse/search entries. Luckily we have phabricator, which already
provides all of this :-) Now we'd just need to add such a repository.
What do you guys think?

I don't think a new place to put example is a good idea, will make the
search of resources more difficult. We have example/test/snippets too much
sparse around: in sources, in the wiki, in examples, in tests... I think we
need a sort of "contentrator" for all that info around.


As I wrote it's not about full examples, just snippets!
Are you familiar with gists? (see http://gist.github.com)
I don't have the time to write out entire examples, but have the time to
copy/paste a few lines I just coded/figured out and add some comments to
them.

Maybe a well done wiki page can be enough, I'm thinking of a sort of "big
index" of resources grouped by libs.


If we'd use a git repository you could use tools of your choice (e.g. grep)
to search the given snippets for matching tags (either we embed them into
the
commit message or into the files).

--
Leif

--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly
thought
leadership blogs to news, videos, case studies, tutorials, tech docs,
whitepapers, evaluation guides, and opinion stories. Check out the most
recent posts - join the conversation now.
http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
(mailto:enlightenment-devel@lists.sourceforge.net
)
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly
thought leadership blogs to news, videos, case studies, tutorials, tech
docs, whitepapers, evaluation guides, and opinion stories. Check out the
most recent posts - join the conversation now.
http://goparallel.sourceforge.net/
___ enlightenment-devel mailing
list enlightenment-devel@lists.sourceforge.net
(mailto:enlightenment-devel@lists.sourceforge.net
)
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



-

Re: [E-devel] EFL Snippet Sharing

[Bruno Dilly]

On Mon, Feb 18, 2013 at 4:53 PM, Leif Middelschulte
 wrote:
> Am Montag, 18. Februar 2013 um 20:34 schrieb Davide Andreoli:
>> 2013/2/18 Leif Middelschulte > (mailto:leif.middelschu...@gmail.com)>
>>
>> > Hello everyone,
>> >
>> > Every few days I come across some functionality that isn't usable
>> > 'straight forward' but isn't explicitly documented either. After asking on
>> > IRC I usually go back to read the library's C code, which sometimes is
>> > quite a bit time consuming.
>> >
>> > Since I strongly believe that many problems and their respective solutions
>> > are reoccurring, I'd like to have some sort of searchable snippets for EFL
>> > usage.
>> >
>> > I'm referring to short snippets, not to full fledged examples that could
>> > be added to examples/ or deserve a blog entry/whatever.
>> >
>> > Let me give you an example:
>> > Problem: Change an edje part's rel1 value via message using embryo
>> > Straight forward solution I assumed:
>> > set_state_val(…)
>> > Real solution:
>> > custom_state(…)
>> > set_state_val(…)
>> > set_state(…)
>> >
>>
>>
>> exactly this is explained in the example:
>> efl/src/examples/edje/embryo_custom_state.edc
>>
>>
>
> I didn't want a custom state. I wanted to modify the current one. So this is 
> - imo - not straight forward! Nevertheless I found an example that showed it.
>> >
>> > Now I'd go and create a snippet that contains only the few correct lines +
>> > comments and tag it with e.g.: "edje part geometry change rel1 embryo
>> > message"
>> >
>> > I imagine a dedicated git repository (e.g. 'snippets') that contains
>> > tagged code snippets (first commit line) and a web interface to eventually
>> > add/edit/browse/search entries. Luckily we have phabricator, which already
>> > provides all of this :-) Now we'd just need to add such a repository.
>> >
>> > What do you guys think?
>>
>> I don't think a new place to put example is a good idea, will make the
>> search of resources more difficult. We have example/test/snippets too much 
>> sparse around: in sources, in the wiki, in examples, in tests... I think we 
>> need a sort of
>> "contentrator" for all that info around.
>
> As I wrote it's not about full examples, just snippets!
> Are you familiar with gists? (see http://gist.github.com)
> I don't have the time to write out entire examples, but have the time to 
> copy/paste a few lines I just coded/figured out and add some comments to them.
>> Maybe a well done wiki page can be enough, I'm thinking of a sort of "big
>> index" of resources grouped by libs.
>
> If we'd use a git repository you could use tools of your choice (e.g. grep) 
> to search the given snippets for matching tags (either we embed them into the 
> commit message or into the files).

My suggestion: go for it. If you think it's useful most probably
somebody else will agree with you and she'll start to use / contribute
snippets.

I prefer to spend my time reading / writing full examples, because you
can build and test them. You are sure it works before spending your
time reading it. And they are useful for testing the lib.

Snippets can be wrong, outdated, etc. I've never used it as a valid
resource in my development flow, but if you like it you should go
ahead with your idea.

>> >
>> > --
>> > Leif
>> >
>> >
>> > --
>> > The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
>> > is your hub for all things parallel software development, from weekly
>> > thought
>> > leadership blogs to news, videos, case studies, tutorials, tech docs,
>> > whitepapers, evaluation guides, and opinion stories. Check out the most
>> > recent posts - join the conversation now.
>> > http://goparallel.sourceforge.net/
>> > ___
>> > enlightenment-devel mailing list
>> > enlightenment-devel@lists.sourceforge.net 
>> > (mailto:enlightenment-devel@lists.sourceforge.net)
>> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>> >
>>
>> --
>> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
>> is your hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials, tech docs,
>> whitepapers, evaluation guides, and opinion stories. Check out the most
>> recent posts - join the conversation now. http://goparallel.sourceforge.net/
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net 
>> (mailto:enlightenment-devel@lists.sourceforge.net)
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
> --
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from 

Re: [E-devel] [PATCH] [Elementary] Patch to fix elementary list with separator

[thiep ha]

Sorry for breaking the mail thread. I haven't known that.
I will use another mail client.

Regards,
Thiep

--- Original Message ---
Sender : Carsten Haitzler 
Date   : Feb 18, 2013 21:24 (GMT+09:00)
Title  : Re: [E-devel] [PATCH] [Elementary] Patch to fix elementary list with
 separator

On Mon, 18 Feb 2013 20:56:51 +0900 Daniel Juyung Seo 
said:

> On Mon, Feb 18, 2013 at 6:29 PM, Carsten Haitzler wrote:
> 
> > On Mon, 18 Feb 2013 17:27:46 +0900 Daniel Juyung Seo  > >
> > said:
> >
> > > On Mon, Feb 18, 2013 at 5:13 PM, Carsten Haitzler  > >wrote:
> > >
> > > > On Wed, 2 Jan 2013 19:13:00 +0900 Daniel Juyung Seo <
> > seojuyu...@gmail.com>
> > > > said:
> > > >
> > > > > Oops Thiep, sorry I didn't review test_list.c
> > > > > So here are more comments.
> > > > >
> > > > > 1. api_data
> > > > > api_data *api = calloc(1, sizeof(api_data));$
> > > > >
> > > > > api_data is not used in test_list_separator() so remove it and
> > related
> > > > > codes.
> > > > >
> > > > > 2. test_list_separator(xxx) indentation
> > > > > Indentations for test_list_separator(xxx) are wrong.
> > > > >
> > > > > +test_list_separator(void*data __UNUSED__,
> > > > > +  Evas_Object *obj __UNUSED__,
> > > > > +  void*event_info __UNUSED__)
> > > > >
> > > > > Thanks.
> > > >
> > > >
> > > Hello
> > >
> > >
> > > > i didnt see a followup from this in email... but some of the patch is
> > in
> > > > svn i
> > > > think at least.. is this done? :)
> > > >
> > >
> > > I guess you missed my reply.
> >
> > its not in my mailer in this thread.. did your mailer break the thread
> > again?
> > (like oh so many people do making it impossible to follow threads). :)
> 
> 
> Well I don't think so. Gmail works very fine with this kind of mail thread.
> The title is still "Re: [E-devel] [PATCH] [Elementary] Patch to fix
> elementary list with separator".
> It should work.

thieps mail broke it. clients break thread by removing the In-Reply-To field in
the header. this is the header that for the past what 15.. 20  years has been
used by mail clients to figure out threads. it knows WHAT mail id this was in
reply to... a mailer will assign a unique id with Message-ID when you send it,
so mail clients can "trace" these id's and reply tos and do a thread correctly
and repliably. thats how it can do multiple levels of nesting etc. too.

gmail GUESSES by the subject being the same with an Re: that it might be a
thread. but it cant know exactly what you reply to like a proper nesting
thread unless you use such mail id's.

bad mail clients are unsociable and break such threads by simply posting a whole
new mail to the list with no context/reference what it is in reply to. it
breaks other peoples ability to track the conversation properly even though
for like 20 years clients have been playing nice. now they just don't bother
and are rude and remove such threading info.

> > > >> Thanks in SVN!
> > > >> Please modify ChangeLog and NEWS files when you fix a bug which was
> > > included in the released version.
> > > >> I did it for you this time.
> > > >> http://trac.enlightenment.org/e/changeset/82040<
> > http://trac.enlightenment.org/e/changeset/82040>
> > > >> http://trac.enlightenment.org/e/changeset/82041
> > >
> > > Daniel Juyung Seo (SeoZ)
> > >
> > >
> > > > > Daniel Juyung Seo (SeoZ)
> > > > >
> > > > > On Wed, Jan 2, 2013 at 6:53 PM, Daniel Juyung Seo <
> > seojuyu...@gmail.com
> > > > >wrote:
> > > > >
> > > > > > Dear Thiep, thanks a lot for your bug fix.
> > > > > > There was an explicit bug on elm list separator.
> > > > > > And I have some comments.
> > > > > >
> > > > > > 1. elementary-1.7
> > > > > > Please support the same patches to elementary-1.7.
> > > > > >
> > > > > > 2. it->deleted checks
> > > > > > it->deleted checks in elm_list.c:600 is not needed.
> > > > > > It was already checked.
> > > > > >
> > > > > > 3. it->separator_themed
> > > > > > separator_themed is not needed.
> > > > > > it->fixed does the same job.
> > > > > >
> > > > > > 4. code structure
> > > > > > I think you can reuse some existing code.
> > > > > > Move 38 ~ 47 lines of your patch to the following parts and reuse
> > the
> > > > code.
> > > > > > if (!it->fixed) ...
> > > > > > If my explanation is ambigous I will do the refactoring once your
> > code
> > > > is
> > > > > > committed.
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > Daniel Juyung Seo (SeoZ)
> > > > > >
> > > > > >
> > > > > > On Sun, Dec 30, 2012 at 3:03 PM, Thiep Ha 
> > wrote:
> > > > > >
> > > > > >> Hi all,
> > > > > >>
> > > > > >> I sent this patch before, but there is no reply.
> > > > > >> So, I resend it.
> > > > > >> Since separators in list are not correctly applied (always have
> > same
> > > > size
> > > > > >> with other items),
> > > > > >> this patch is sent to fix that.
> > > > > >> Could someone review it?
> > > > > >>
> > > > > >> Thanks,
> > > > > >> Thiep
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> From: thiep ha 
> >

Re: [E-devel] E SVN: discomfitor IN trunk/e: . data/themes/edc src/bin src/modules/backlight src/modules/conf_comp src/modules/connman src/modules/fileman src/modules/gadman src/modules/illume-keyboar

[The Rasterman]

On Mon, 18 Feb 2013 05:43:48 -0800 "Enlightenment SVN"
 said:

> Log:
> giant comp rejiggering commit #2: popups are now objects drawn directly onto
> the compositor canvas with no xwindows of their own 
>   * added a number of new e_comp functions and macros
>   
>   * options for disabling effects on objects: this option does not currently
> have any effect 
>   * all modules which used gadcon popups have been adjusted
>   
>   * all modules which used input windows to detect close events for gadcon
> popups have been adjusted to use new popup autoclose functionality 
>   * shelves are now always drawn on the compositor canvas, meaning objects
> will never get clipped by the shelf (ticket #1810) 
>   * shelves no longer have an event object

just so you know... this was almost "awesome"... but we now have a few problems:

1. shelf lost its shadow. same with all popups i see actually (menus are ok)
2. popups for mixer instantly hide when clicked rather than staying around
3. dnd of windows between pagers in shelf is now not working. same with dnd of
icons form window borders to pager. i guess dnd for ibar and ibox are broken
too?
4. some menus disappear instantly (deleted objects). this should now get
delayed to allow the hide anim to finish then delete (eg use a timer and keep
objects around yet "suspended" until timer expires)... probably should be
handled inside e_popup and e_menu... :)
5. popups seem to "swim in" (shift down and to the right by a few pixels) when
they show.
6. this is not your problem.. but one in gl... now icons are gadgets scale
down with lower quality (due to opengl not actually seeming to do much when
anisotropic filtering is set to max (eg 8 or 16) and we still use linear down
scaling... i thought it was meant to do multi-sampling even in these cases?)...
methinks we need to finally get on with it and make a scalecache for gl
here... :) (ie mipmapping... but manually).

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


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Platform specific engine new function

[The Rasterman]

On Mon, 18 Feb 2013 23:22:09 +0100 Andreas Volz  said:

> Hello,
> 
> while writing a new Android engine I don't see how you set the platform
> specific engine new function. e.g. for FB in ecore_evas.h
> 
> EAPI Ecore_Evas *
> ecore_evas_fb_new(const char *disp_name, int rotation, int w, int h)
> 
> In this case there're only basic types. But for the case that I have a
> special platform dependant drawing handle how would I do this?
> 
> Would you suggest to define a void* and simply cast it in the engine
> itself? Is this the desired way at this point?
> 
> regards
>   Andreas

well the fb engine is kind of generic "talk to the raw framebuffer". how it
does this isnt too important except that ecore-evas assumes this is the linux
framebuffer with vt's etc. and the evas engine is written for this too. you may
want an android_fb ecore_evas api and support...? unless this is not the fb and
its "the windowing system" (surfaceflinger)...

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


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] elm_index: add omit feature

[The Rasterman]

On Mon, 18 Feb 2013 19:44:00 +0900 (KST) Jaeun Choi  said:

> This patch adds omit feature to elm_index.
>  
> - not support horizontal mode 
> - enabled when at least 3 items can be displayed (first and last items are
> not omitted)
> - not work when having too many items (patch line 270)
>  
> I appreciate your review. Thanks.
>

i have a plan... and it is to use phab for this...

https://phab.enlightenment.org/D1

in fact i'd like to ask people to submit patches via phab in future... now i
need to figure out how to give this context - is what git repo it should apply
to and what dir etc.

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


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: stefan trunk/elementary/src/lib

[ChunEon Park]

I'm not sure. is it right fix?
  
-Regards, Hermet-

-Original Message-
From: "Enlightenment SVN" 
To: ; 
Cc: 
Sent: 2012-12-19 (수) 19:28:21
Subject: E SVN: stefan trunk/elementary/src/lib

Log:
elm/map: Free buffer on error path

Author:   stefan
Date: 2012-12-19 02:28:20 -0800 (Wed, 19 Dec 2012)
New Revision: 81342
Trac: http://trac.enlightenment.org/e/changeset/81342

Modified:
  trunk/elementary/src/lib/elm_map.c 

Modified: trunk/elementary/src/lib/elm_map.c
===
--- trunk/elementary/src/lib/elm_map.c2012-12-19 10:02:48 UTC (rev 81341)
+++ trunk/elementary/src/lib/elm_map.c2012-12-19 10:28:20 UTC (rev 81342)
@@ -2941,6 +2941,8 @@
eina_simple_xml_parse
  (buf, sz, EINA_TRUE, _xml_name_dump_list_cb, nl);
 }
+  else
+free(buf);
}
   }
 fclose(f);


--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn

 
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] elm_index: add omit feature

[The Rasterman]

On Mon, 18 Feb 2013 19:44:00 +0900 (KST) Jaeun Choi  said:

> This patch adds omit feature to elm_index.
>  
> - not support horizontal mode 
> - enabled when at least 3 items can be displayed (first and last items are
> not omitted)
> - not work when having too many items (patch line 270)
>  
> I appreciate your review. Thanks.

i've clowncopertized this:

https://phab.enlightenment.org/D1

(errr apparently that is phab-speak for having reviewed/commented on it).

lets try use this phab thing for reviews... i hope then to figure out how the
hell to use it to "apply an approved patch" :)

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


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: discomfitor IN trunk/e: . data/themes/edc src/bin src/modules/backlight src/modules/conf_comp src/modules/connman src/modules/fileman src/modules/gadman src/modules/illume-keyboar

[Michael Blumenkrantz]

this is all that broke? notbad.jpg

On Tue, Feb 19, 2013 at 5:01 AM, Carsten Haitzler wrote:

> On Mon, 18 Feb 2013 05:43:48 -0800 "Enlightenment SVN"
>  said:
>
> > Log:
> > giant comp rejiggering commit #2: popups are now objects drawn directly
> onto
> > the compositor canvas with no xwindows of their own
> >   * added a number of new e_comp functions and macros
> >
> >   * options for disabling effects on objects: this option does not
> currently
> > have any effect
> >   * all modules which used gadcon popups have been adjusted
> >
> >   * all modules which used input windows to detect close events for
> gadcon
> > popups have been adjusted to use new popup autoclose functionality
> >   * shelves are now always drawn on the compositor canvas, meaning
> objects
> > will never get clipped by the shelf (ticket #1810)
> >   * shelves no longer have an event object
>
> just so you know... this was almost "awesome"... but we now have a few
> problems:
>
> 1. shelf lost its shadow. same with all popups i see actually (menus are
> ok)
> 2. popups for mixer instantly hide when clicked rather than staying around
> 3. dnd of windows between pagers in shelf is now not working. same with
> dnd of
> icons form window borders to pager. i guess dnd for ibar and ibox are
> broken
> too?
> 4. some menus disappear instantly (deleted objects). this should now get
> delayed to allow the hide anim to finish then delete (eg use a timer and
> keep
> objects around yet "suspended" until timer expires)... probably should be
> handled inside e_popup and e_menu... :)
> 5. popups seem to "swim in" (shift down and to the right by a few pixels)
> when
> they show.
> 6. this is not your problem.. but one in gl... now icons are gadgets scale
> down with lower quality (due to opengl not actually seeming to do much when
> anisotropic filtering is set to max (eg 8 or 16) and we still use linear
> down
> scaling... i thought it was meant to do multi-sampling even in these
> cases?)...
> methinks we need to finally get on with it and make a scalecache for gl
> here... :) (ie mipmapping... but manually).
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: discomfitor IN trunk/e: . data/themes/edc src/bin src/modules/backlight src/modules/conf_comp src/modules/connman src/modules/fileman src/modules/gadman src/modules/illume-keyboar

[The Rasterman]

On Tue, 19 Feb 2013 07:38:39 + Michael Blumenkrantz
 said:

> this is all that broke? notbad.jpg

as i said.. almost awesome. :) just letting u know what i've seen so far :)

> On Tue, Feb 19, 2013 at 5:01 AM, Carsten Haitzler wrote:
> 
> > On Mon, 18 Feb 2013 05:43:48 -0800 "Enlightenment SVN"
> >  said:
> >
> > > Log:
> > > giant comp rejiggering commit #2: popups are now objects drawn directly
> > onto
> > > the compositor canvas with no xwindows of their own
> > >   * added a number of new e_comp functions and macros
> > >
> > >   * options for disabling effects on objects: this option does not
> > currently
> > > have any effect
> > >   * all modules which used gadcon popups have been adjusted
> > >
> > >   * all modules which used input windows to detect close events for
> > gadcon
> > > popups have been adjusted to use new popup autoclose functionality
> > >   * shelves are now always drawn on the compositor canvas, meaning
> > objects
> > > will never get clipped by the shelf (ticket #1810)
> > >   * shelves no longer have an event object
> >
> > just so you know... this was almost "awesome"... but we now have a few
> > problems:
> >
> > 1. shelf lost its shadow. same with all popups i see actually (menus are
> > ok)
> > 2. popups for mixer instantly hide when clicked rather than staying around
> > 3. dnd of windows between pagers in shelf is now not working. same with
> > dnd of
> > icons form window borders to pager. i guess dnd for ibar and ibox are
> > broken
> > too?
> > 4. some menus disappear instantly (deleted objects). this should now get
> > delayed to allow the hide anim to finish then delete (eg use a timer and
> > keep
> > objects around yet "suspended" until timer expires)... probably should be
> > handled inside e_popup and e_menu... :)
> > 5. popups seem to "swim in" (shift down and to the right by a few pixels)
> > when
> > they show.
> > 6. this is not your problem.. but one in gl... now icons are gadgets scale
> > down with lower quality (due to opengl not actually seeming to do much when
> > anisotropic filtering is set to max (eg 8 or 16) and we still use linear
> > down
> > scaling... i thought it was meant to do multi-sampling even in these
> > cases?)...
> > methinks we need to finally get on with it and make a scalecache for gl
> > here... :) (ie mipmapping... but manually).
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am" --
> > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> >
> >
> >
> > --
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics
> > Download AppDynamics Lite for free today:
> > http://p.sf.net/sfu/appdyn_d2d_feb
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


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


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Query] Controlling further eventing on an edje draggable part programmatically

[The Rasterman]

On Mon, 18 Feb 2013 11:34:36 + (GMT) Rajeev Ranjan 
said:

> Hi Raster,
> > --- Original Message ---
> > Sender : Carsten Haitzler
> > Date : Feb 18, 2013 12:39 (GMT+09:00)
> > Title : Re: [E-devel] [Query] Controlling further eventing on an edje
> > draggable part programmatically
> > 
> > On Fri, 15 Feb 2013 11:43:21 + (GMT) Rajeev Ranjan 
> > said:
> > 
> >> Hi,
> >> > --- Original Message ---
> >> > Sender : Carsten Haitzler
> >> > Date : Feb 15, 2013 20:15 (GMT+09:00)
> >> >Title : Re: [E-devel] [Query] Controlling further eventing on an edje
> >> >draggable part programmatically
> >> > 
> >> > On Fri, 15 Feb 2013 11:02:13 + (GMT) Rajeev Ranjan 
> >> said:
> >> >
> >> >> Hi,
> >> >>   I have a requirement where on certain event like on resize I dont
> >> >> want to keep allowing dragging for an edje draggable part even if
> >> >> mouse,up/touch,up has not yet been done after mouse,down.
> >> >
> >> > this sounds odd. can you please expand on why you need/want this?
> >> >
> >>Basically my requirement is related to elm_panes(vertical) where in
> >> landscape mode we have both contents set and in portrait mode, we have
> >> single content set and left size set to 1.0 to hide the other content
> >> area. Now when we tap on handler in panes in landscape mode and without
> >> lifting finger, rotate the device to portrait mode, then still the handler
> >> can be dragged. In this case, it is unwanted if there is a single content
> >> in portrait mode and the other one is unset when mode is portrait.
> >
> > hmmm ok - it smells more to me that you need a feature in the elm panes
> > widget to be able to go in "show only one element" mode (and maybe choose
> > that element - top/bottom etc.) it sounds to me like you then want to emit
> > a signal to the panes edje obj to tell it to go into "1 content only" and
> > indicate which one, or to go back to normal "2 items".
> Yes, this is infact the actual requirement in panes however this kind of
> requirement is not limited to panes only. E.g. in slider as well, we don't
> want to have the dragging happening on rotation as because of window resize
> the touch point position will change and will be having different position
> than that of indicator. Further I made the handler(draggable part) invisible
> when there be a single content(the other one is unset on rotation), still the
> handler continued to take events[At the time of drag start, handler was
> visible]. Please tell me if there can be a way by which we can stop further
> dragging programmatically for draggable part.

you can't - the grab is still active on the dragable until the finger is
released regardless of the visibility. the only way to stop it is to delete the
object entirely.

> > > >> For this, I used pointer_mode: NOGRAB for draggable part but it didn't
> > > >> work in case of draggable as it kept taking drag events even if the
> > > >> mouse/touch was outside draggable geometry. Even synthesizing
> > > >> mouse,up,1 with source "" in edc had no effect and drag event was
> > > >> continuously going to the draggable part.
> > > >
> > > > nograb is a totally different thing to what you want i think.. so it's
> > > > not going to help :)
> > > >>
> > > I tested pointer_mode with NOGRAB option for parts other than draggable
> > > and found that the events outside the part geometry are ignored in this
> > > case (including mouse,up), so I thought that may be this should work with
> > > draggable as well.
> > > 
> > > >> Please let me know if there is any way we can control this (avoiding
> > > >> further drag event for a drag part) programmatically.
> > > >> 
> > > >> Thank you.
> > > >> Regards,
> > > >> Rajeev
> > > >> --
> 
> > > > - Codito, ergo sum - "I code, therefore I am" --
> > > > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> > > 
> > > Thank you.
> > > Regards,
> > > Rajeev
> > --
> > -- 
> > - Codito, ergo sum - "I code, therefore I am" --
> > The Rasterman (Carsten Haitzler)ras...@rasterman.com
> 
> Thank you.
> Regards,
> Rajeev
> --
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
> is your hub for all things parallel software development, from weekly thought 
> leadership blogs to news, videos, case studies, tutorials, tech docs, 
> whitepapers, evaluation guides, and opinion stories. Check out the most 
> recent posts - join the conversation now. http://goparallel.sourceforge.net/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
- Codito, ergo sum - "I code, therefore I