Re: [E-devel] E SVN: devilhorns trunk/evas
2012/7/3 Enlightenment SVN : > Log: > Evas: Update ChangeLog wrt Tizen Merge. > > NB: This is the commit message inside tizen git for this commit. Don't > blame me if the message is not detailed enough for you. Complain to > the original committer about making more detailed commit messages. > I say we reject changes unless they specify clearly what they do. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas
On 03/07/12 17:34, Iván Briano wrote: > 2012/7/3 Enlightenment SVN : >> Log: >> Evas: Update ChangeLog wrt Tizen Merge. >> >> NB: This is the commit message inside tizen git for this commit. Don't >> blame me if the message is not detailed enough for you. Complain to >> the original committer about making more detailed commit messages. >> > > I say we reject changes unless they specify clearly what they do. Yeah, we even talked about it on IRC and you agreed... You should not commit things you don't know what they do. You can't know if the commit is correct, buggy, or implements an unwanted behaviour. -- Tom. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas
Agree. -Regards, Hermet- -Original Message- From: "Iván Briano" To: ; Cc: ; Sent: 2012-07-03 (화) 23:34:33 Subject: Re: [E-devel] E SVN: devilhorns trunk/evas 2012/7/3 Enlightenment SVN @enlightenment.org>: > Log: > Evas: Update ChangeLog wrt Tizen Merge. > > NB: This is the commit message inside tizen git for this commit. Don't > blame me if the message is not detailed enough for you. Complain to > the original committer about making more detailed commit messages. > I say we reject changes unless they specify clearly what they do. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas
On Tue, 03 Jul 2012 17:45:57 +0300 Tom Hacohen said: > On 03/07/12 17:34, Iván Briano wrote: > > 2012/7/3 Enlightenment SVN : > >> Log: > >> Evas: Update ChangeLog wrt Tizen Merge. > >> > >> NB: This is the commit message inside tizen git for this commit. Don't > >> blame me if the message is not detailed enough for you. Complain to > >> the original committer about making more detailed commit messages. > >> > > > > I say we reject changes unless they specify clearly what they do. > > Yeah, we even talked about it on IRC and you agreed... You should not > commit things you don't know what they do. You can't know if the commit > is correct, buggy, or implements an unwanted behaviour. that's part of a merge or review process. you need to find all the changes, break them up into features/sets and have info what it does and why and who did it and THEN commit that. but get that info together. i've done this before. it took me months. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas
2012/7/3 Carsten Haitzler : > On Tue, 03 Jul 2012 17:45:57 +0300 Tom Hacohen said: > >> On 03/07/12 17:34, Iván Briano wrote: >> > 2012/7/3 Enlightenment SVN : >> >> Log: >> >> Evas: Update ChangeLog wrt Tizen Merge. >> >> >> >> NB: This is the commit message inside tizen git for this commit. Don't >> >> blame me if the message is not detailed enough for you. Complain to >> >> the original committer about making more detailed commit messages. >> >> >> > >> > I say we reject changes unless they specify clearly what they do. >> >> Yeah, we even talked about it on IRC and you agreed... You should not >> commit things you don't know what they do. You can't know if the commit >> is correct, buggy, or implements an unwanted behaviour. > > that's part of a merge or review process. you need to find all the changes, > break them up into features/sets and have info what it does and why and who > did > it and THEN commit that. but get that info together. i've done this before. it > took me months. > And we are going through that again? Future changes will be the same or will the people behind those changes learn to keep enough of a history to make merging easier? It sounds a lot like they don't give a damn. > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas
From: "Iván Briano" To: "Enlightenment developer list" Cc: enlightenment-...@lists.sourceforge.net Sent: Tuesday, July 3, 2012 3:52:45 PM Subject: Re: [E-devel] E SVN: devilhorns trunk/evas 2012/7/3 Carsten Haitzler : > On Tue, 03 Jul 2012 17:45:57 +0300 Tom Hacohen said: > >> On 03/07/12 17:34, Iván Briano wrote: >> > 2012/7/3 Enlightenment SVN : >> >> Log: >> >> Evas: Update ChangeLog wrt Tizen Merge. >> >> >> >> NB: This is the commit message inside tizen git for this commit. Don't >> >> blame me if the message is not detailed enough for you. Complain to >> >> the original committer about making more detailed commit messages. >> >> >> > >> > I say we reject changes unless they specify clearly what they do. >> >> Yeah, we even talked about it on IRC and you agreed... You should not >> commit things you don't know what they do. You can't know if the commit >> is correct, buggy, or implements an unwanted behaviour. > > that's part of a merge or review process. you need to find all the changes, > break them up into features/sets and have info what it does and why and who > did > it and THEN commit that. but get that info together. i've done this before. > it > took me months. > >And we are going through that again? Future changes will be the same or will >the people behind those changes learn to keep enough of a history to make >merging easier? It sounds a lot like they don't give a damn. Well, that makes all this merging nice and simple then. Ok, merging done !! :) Since none (or hardly any) of the tizen git commits rarely ever specify what they do/or fix, then none (or hardly any) of it will get committed anymore. Makes the process much simplier ;) On a serious note tho, alright no problem. I can spend the time tracking down the people who did the commits and getting some sort or (hopefully) sane response from them about what it fixes, etc, etc. Then apply & testassuming that goes well, then maybe commit. Just be aware that, like you said raster, it may take months. dh > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > -- > > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas
From: "Iván Briano" To: "Enlightenment developer list" Cc: enlightenment-...@lists.sourceforge.net Sent: Tuesday, July 3, 2012 3:52:45 PM Subject: Re: [E-devel] E SVN: devilhorns trunk/evas 2012/7/3 Carsten Haitzler : > On Tue, 03 Jul 2012 17:45:57 +0300 Tom Hacohen said: > >> On 03/07/12 17:34, Iván Briano wrote: >> > 2012/7/3 Enlightenment SVN : >> >> Log: >> >> Evas: Update ChangeLog wrt Tizen Merge. >> >> >> >> NB: This is the commit message inside tizen git for this commit. Don't >> >> blame me if the message is not detailed enough for you. Complain to >> >> the original committer about making more detailed commit messages. >> >> >> > >> > I say we reject changes unless they specify clearly what they do. Should that also include changes to our own svn from our own developers who don't put in commit messages that mention what the commit fixes ?? I would think so based on this reasoning. dh >> >> Yeah, we even talked about it on IRC and you agreed... You should not >> commit things you don't know what they do. You can't know if the commit >> is correct, buggy, or implements an unwanted behaviour. > > that's part of a merge or review process. you need to find all the changes, > break them up into features/sets and have info what it does and why and who > did > it and THEN commit that. but get that info together. i've done this before. > it > took me months. > And we are going through that again? Future changes will be the same or will the people behind those changes learn to keep enough of a history to make merging easier? It sounds a lot like they don't give a damn. > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > -- > > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas
On 03/07/12 18:31, cpmicha...@comcast.net wrote: > Well, that makes all this merging nice and simple then. Ok, merging done !! > :) Since none (or hardly any) of the tizen git commits rarely ever specify > what they do/or fix, then none (or hardly any) of it will get committed > anymore. Makes the process much simplier ;) > > > On a serious note tho, alright no problem. I can spend the time tracking down > the people who did the commits and getting some sort or (hopefully) sane > response from them about what it fixes, etc, etc. Then apply & > testassuming that goes well, then maybe commit. Just be aware that, like > you said raster, it may take months. You can alternatively just read the patches and find out what they are supposed to do and write changelog entries, news entries and commit logs accordingly. :) Would probably be easier. -- Tom. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas
On 03/07/12 18:33, cpmicha...@comcast.net wrote: > Should that also include changes to our own svn from our own developers who > don't put in commit messages that mention what the commit fixes ?? I would > think so based on this reasoning. > Of course, and I think developers are finally starting to do it better. Either way, it's something everyone is trying to improve, and I don't think you should compare yourself to the lowest standard, but to the highest. :) Furthermore, I'm pretty sure you agree anyway and just grumpy because you have a very annoying task at hand. :) -- Tom. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas
From: "Tom Hacohen" To: "Enlightenment developer list" Cc: cpmicha...@comcast.net, enlightenment-...@lists.sourceforge.net Sent: Tuesday, July 3, 2012 4:41:30 PM Subject: Re: [E-devel] E SVN: devilhorns trunk/evas On 03/07/12 18:33, cpmicha...@comcast.net wrote: > Should that also include changes to our own svn from our own developers who > don't put in commit messages that mention what the commit fixes ?? I would > think so based on this reasoning. > >Of course, and I think developers are finally starting to do it better. >Either way, it's something everyone is trying to improve, and I don't >think you should compare yourself to the lowest standard, but to the >highest. :) Thanks Tom...actually made me smile with this one :) >Furthermore, I'm pretty sure you agree anyway and just grumpy because >you have a very annoying task at hand. :) Yea, I do agree. Na, I was grumpy for other reasons (that I am not going to go into here) but rest assured, it's not the task which did it ;) I don't mind the work at all :) In fact, happy to do it :) dh -- Tom. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas
2012/7/3 : > From: "Tom Hacohen" > To: "Enlightenment developer list" > Cc: cpmicha...@comcast.net, enlightenment-...@lists.sourceforge.net > Sent: Tuesday, July 3, 2012 4:41:30 PM > Subject: Re: [E-devel] E SVN: devilhorns trunk/evas > > On 03/07/12 18:33, cpmicha...@comcast.net wrote: >> Should that also include changes to our own svn from our own developers who >> don't put in commit messages that mention what the commit fixes ?? I would >> think so based on this reasoning. >> > >>Of course, and I think developers are finally starting to do it better. >>Either way, it's something everyone is trying to improve, and I don't >>think you should compare yourself to the lowest standard, but to the >>highest. :) > > Thanks Tom...actually made me smile with this one :) > >>Furthermore, I'm pretty sure you agree anyway and just grumpy because >>you have a very annoying task at hand. :) > > Yea, I do agree. Na, I was grumpy for other reasons (that I am not going to > go into here) but rest assured, it's not the task which did it ;) I don't > mind the work at all :) In fact, happy to do it :) > > Crappy commits from our own developers still have the accountability factor that these huge Tizen blobs don't have. We should improve our messages to be more clear, but what I would really like to see happening from these merges is the Tizen people learning how to properly cooperate with an open source project instead of just dumping code and expecting them to merge it themselves. I don't see that happening if we are always cleaning up their mess. > dh > > -- > Tom. > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas
On Tue, Jul 3, 2012 at 1:27 PM, Iván Briano wrote: > > 2012/7/3 : > > From: "Tom Hacohen" > > To: "Enlightenment developer list" > > > > Cc: cpmicha...@comcast.net, enlightenment-...@lists.sourceforge.net > > Sent: Tuesday, July 3, 2012 4:41:30 PM > > Subject: Re: [E-devel] E SVN: devilhorns trunk/evas > > > > On 03/07/12 18:33, cpmicha...@comcast.net wrote: > >> Should that also include changes to our own svn from our own developers > >> who don't put in commit messages that mention what the commit fixes ?? I > >> would think so based on this reasoning. > >> > > > >>Of course, and I think developers are finally starting to do it better. > >>Either way, it's something everyone is trying to improve, and I don't > >>think you should compare yourself to the lowest standard, but to the > >>highest. :) > > > > Thanks Tom...actually made me smile with this one :) > > > >>Furthermore, I'm pretty sure you agree anyway and just grumpy because > >>you have a very annoying task at hand. :) > > > > Yea, I do agree. Na, I was grumpy for other reasons (that I am not going to > > go into here) but rest assured, it's not the task which did it ;) I don't > > mind the work at all :) In fact, happy to do it :) > > > > > > Crappy commits from our own developers still have the accountability factor > that these huge Tizen blobs don't have. We should improve our messages to > be more clear, but what I would really like to see happening from these merges > is the Tizen people learning how to properly cooperate with an open source > project instead of just dumping code and expecting them to merge it > themselves. > I don't see that happening if we are always cleaning up their mess. +1 and having to maintain these patches out-of-tree is totally their burden, not ours. Then no need to hurry the patches in, if you do so they become our problem. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas
On Tue, 03 Jul 2012 18:34:53 +0300 Tom Hacohen said: > On 03/07/12 18:31, cpmicha...@comcast.net wrote: > > Well, that makes all this merging nice and simple then. Ok, merging > > done !! :) Since none (or hardly any) of the tizen git commits rarely ever > > specify what they do/or fix, then none (or hardly any) of it will get > > committed anymore. Makes the process much simplier ;) > > > > > > On a serious note tho, alright no problem. I can spend the time tracking > > down the people who did the commits and getting some sort or (hopefully) > > sane response from them about what it fixes, etc, etc. Then apply & > > testassuming that goes well, then maybe commit. Just be aware that, > > like you said raster, it may take months. > > You can alternatively just read the patches and find out what they are > supposed to do and write changelog entries, news entries and commit logs > accordingly. :) Would probably be easier. yup. you my find the right solution is a combination of isolating things you can see have an obvious need/use, and things that go together, and thing that make you go "hmm". -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas
From: "Carsten Haitzler (The Rasterman)" To: "Enlightenment developer list" Cc: enlightenment-...@lists.sourceforge.net Sent: Tuesday, July 3, 2012 6:23:04 PM Subject: Re: [E-devel] E SVN: devilhorns trunk/evas On Tue, 03 Jul 2012 18:34:53 +0300 Tom Hacohen said: > On 03/07/12 18:31, cpmicha...@comcast.net wrote: > > Well, that makes all this merging nice and simple then. Ok, merging > > done !! :) Since none (or hardly any) of the tizen git commits rarely ever > > specify what they do/or fix, then none (or hardly any) of it will get > > committed anymore. Makes the process much simplier ;) > > > > > > On a serious note tho, alright no problem. I can spend the time tracking > > down the people who did the commits and getting some sort or (hopefully) > > sane response from them about what it fixes, etc, etc. Then apply & > > testassuming that goes well, then maybe commit. Just be aware that, > > like you said raster, it may take months. > > You can alternatively just read the patches and find out what they are > supposed to do and write changelog entries, news entries and commit logs > accordingly. :) Would probably be easier. >yup. you my find the right solution is a combination of isolating things you >can see have an obvious need/use, and things that go together, and thing that >make you go "hmm". If that is your recommendation raster, then I'll do it that way mate :) Cheers, dh -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler) ras...@rasterman.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/m4
using xcb-aux is a bad idea
Vincent
On Thu, 7 Jul 2011, Enlightenment SVN wrote:
> Log:
> Evas: Fix up the check_engine macros for xcb engine & xlib changes.
>
>
>
> Author: devilhorns
> Date: 2011-07-07 17:18:22 -0700 (Thu, 07 Jul 2011)
> New Revision: 61137
> Trac: http://trac.enlightenment.org/e/changeset/61137
>
> Modified:
> trunk/evas/m4/evas_check_engine.m4
>
> Modified: trunk/evas/m4/evas_check_engine.m4
> ===
> --- trunk/evas/m4/evas_check_engine.m42011-07-08 00:17:52 UTC (rev
> 61136)
> +++ trunk/evas/m4/evas_check_engine.m42011-07-08 00:18:22 UTC (rev
> 61137)
> @@ -64,9 +64,9 @@
>
> ])
>
> -dnl use: EVAS_CHECK_ENGINE_DEP_GL_X11(engine, simple, want_static[,
> ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
> +dnl use: EVAS_CHECK_ENGINE_DEP_GL_XLIB(engine, simple, want_static[,
> ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
>
> -AC_DEFUN([EVAS_CHECK_ENGINE_DEP_GL_X11],
> +AC_DEFUN([EVAS_CHECK_ENGINE_DEP_GL_XLIB],
> [
>
> evas_engine_[]$1[]_cflags=""
> @@ -187,10 +187,10 @@
> evas_engine_[]$1[]_libs=""
>
> PKG_CHECK_MODULES([XCB],
> - [xcb xcb-shm xcb-image >= 0.2.1 pixman-1],
> + [xcb xcb-shm xcb-image >= 0.2.1 xcb-aux pixman-1],
>[
> have_dep="yes"
> -requirement="xcb xcb-shm xcb-image pixman-1"
> +requirement="xcb xcb-shm xcb-image xcb-aux pixman-1"
> evas_engine_[]$1[]_cflags="${XCB_CFLAGS}"
> evas_engine_[]$1[]_libs="${XCB_LIBS}"
>],[
> @@ -213,6 +213,123 @@
>
> ])
>
> +
> +dnl use: EVAS_CHECK_ENGINE_DEP_GL_XCB(engine, simple, want_static[,
> ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
> +
> +AC_DEFUN([EVAS_CHECK_ENGINE_DEP_GL_XCB],
> +[
> +
> +evas_engine_[]$1[]_cflags=""
> +evas_engine_[]$1[]_libs=""
> +
> +AC_PATH_X
> +AC_PATH_XTRA
> +
> +AC_CHECK_HEADER([GL/gl.h],
> + [have_dep="yes"],
> + [have_dep="no"],
> + [
> +#include
> +#include
> +#include
> + ])
> +
> +gl_pt_lib="";
> +have_gl_pt="no"
> +AC_CHECK_LIB([pthread], [pthread_create], [have_gl_pt="yes"],
> [have_gl_pt="no"])
> +if test "x$have_gl_pt" = "xyes" ; then
> + gl_pt_lib=" -lpthread"
> +fi
> +
> +if test "x${have_dep}" = "xyes" ; then
> + AC_CHECK_LIB([X11], [XCreateColormap], [have_dep="yes"], [have_dep="no"])
> +fi
> +
> +if test "x${have_dep}" = "xyes" ; then
> + AC_CHECK_LIB([Xrender], [XRenderCreatePicture], [have_dep="yes"],
> [have_dep="no"])
> +fi
> +
> +if test "x${have_dep}" = "xyes" ; then
> + AC_CHECK_LIB([GL], [glXCreateContext], [have_dep="yes"], [have_dep="no"],
> -lX11 -lXext -lXrender -lm $gl_pt_lib)
> +fi
> +
> +PKG_CHECK_MODULES([XCB_GL],
> + [x11-xcb xcb xcb-aux xcb-glx xcb-render xcb-renderutil],
> + [
> +have_dep="yes"
> +requirement="x11-xcb xcb xcb-aux xcb-glx xcb-render xcb-renderutil"
> +evas_engine_[]$1[]_cflags="${XCB_GL_CFLAGS}"
> +evas_engine_[]$1[]_libs="${XCB_GL_LIBS}"
> + ],[
> +have_dep="no"
> + ]
> +)
> +
> +if test "x$gl_flavor_gles" = "xyes" ; then
> + have_dep=no
> +fi
> +
> +if test "x${have_dep}" = "xyes" ; then
> + PKG_CHECK_MODULES([GL_EET], [eet >= 1.4.0], [have_dep="yes"],
> [have_dep="no"])
> + if test "x${have_dep}" = "xyes" ; then
> + if test "x$2" = "xyes" ; then
> + x_libs="${x_libs} -lX11 -lXext -lXrender"
> + else
> + x_dir=${x_dir:-/usr/X11R6}
> + x_cflags=${x_cflags:--I${x_includes:-$x_dir/include}}
> + x_libs="${x_libs:--L${x_libraries:-$x_dir/lib}} -lX11 -lXext
> -lXrender"
> + fi
> + evas_engine_[]$1[]_cflags="-I/usr/include ${XCB_GL_CFLAGS} ${x_cflags}"
> + evas_engine_[]$1[]_libs="${XCB_GL_LIBS} ${x_libs} -lGL $gl_pt_lib"
> + evas_engine_gl_common_libs="-lGL $gl_pt_lib"
> + fi
> +else
> + if test "x$2" = "xyes" ; then
> + x_libs="${x_libs} -lX11 -lXext -lXrender"
> + else
> + x_dir=${x_dir:-/usr/X11R6}
> + x_cflags=${x_cflags:--I${x_includes:-$x_dir/include}}
> + x_libs="${x_libs:--L${x_libraries:-$x_dir/lib}} -lX11 -lXext -lXrender"
> + fi
> + AC_CHECK_HEADER([GLES2/gl2.h],
> + [have_egl="yes"],
> + [have_egl="no"],
> + [
> +#include
> +#include
> +#include
> + ])
> + if test "x${have_egl}" = "xyes" ; then
> + AC_CHECK_LIB(GLESv2, glTexImage2D, [have_glesv2="yes"], , -lEGL
> ${x_libs} -lm $gl_pt_lib)
> + if test "x${have_glesv2}" = "xyes" ; then
> + PKG_CHECK_MODULES([GL_EET], [eet >= 1.4.0], [have_dep="yes"],
> [have_dep="no"])
> + if test "x${have_dep}" = "xyes" ; then
> +evas_engine_[]$1[]_cflags="${XCB_GL_CFLAGS} ${x_cflags}"
> +evas_engine_[]$1[]_libs="${XCB_GL_LIBS} ${x_libs} -lGLESv2 -lEGL
> -lm $gl_pt_lib"
> +evas_engine_gl_common_libs="-lGLESv2 -lm $gl_pt_lib"
> +have_dep="yes"
> +gl_flavor_gles="no"
> +AC_DEFINE(GLES_VARIETY_SGX, 1, [Imagination SGX GLES2 support])
> +gles_variety_sgx="yes"
> + fi
> + fi
> + fi
> +fi
> +
> +AC_SUBST([evas_engi
Re: [E-devel] E SVN: devilhorns trunk/evas/m4
Why ?
dh
On 07/08/11 11:10, Vincent Torri wrote:
>
> using xcb-aux is a bad idea
>
> Vincent
>
> On Thu, 7 Jul 2011, Enlightenment SVN wrote:
>
>> Log:
>> Evas: Fix up the check_engine macros for xcb engine& xlib changes.
>>
>>
>>
>> Author: devilhorns
>> Date: 2011-07-07 17:18:22 -0700 (Thu, 07 Jul 2011)
>> New Revision: 61137
>> Trac: http://trac.enlightenment.org/e/changeset/61137
>>
>> Modified:
>> trunk/evas/m4/evas_check_engine.m4
>>
>> Modified: trunk/evas/m4/evas_check_engine.m4
>> ===
>> --- trunk/evas/m4/evas_check_engine.m4 2011-07-08 00:17:52 UTC (rev
>> 61136)
>> +++ trunk/evas/m4/evas_check_engine.m4 2011-07-08 00:18:22 UTC (rev
>> 61137)
>> @@ -64,9 +64,9 @@
>>
>> ])
>>
>> -dnl use: EVAS_CHECK_ENGINE_DEP_GL_X11(engine, simple, want_static[,
>> ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
>> +dnl use: EVAS_CHECK_ENGINE_DEP_GL_XLIB(engine, simple, want_static[,
>> ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
>>
>> -AC_DEFUN([EVAS_CHECK_ENGINE_DEP_GL_X11],
>> +AC_DEFUN([EVAS_CHECK_ENGINE_DEP_GL_XLIB],
>> [
>>
>> evas_engine_[]$1[]_cflags=""
>> @@ -187,10 +187,10 @@
>> evas_engine_[]$1[]_libs=""
>>
>> PKG_CHECK_MODULES([XCB],
>> - [xcb xcb-shm xcb-image>= 0.2.1 pixman-1],
>> + [xcb xcb-shm xcb-image>= 0.2.1 xcb-aux pixman-1],
>> [
>> have_dep="yes"
>> -requirement="xcb xcb-shm xcb-image pixman-1"
>> +requirement="xcb xcb-shm xcb-image xcb-aux pixman-1"
>> evas_engine_[]$1[]_cflags="${XCB_CFLAGS}"
>> evas_engine_[]$1[]_libs="${XCB_LIBS}"
>> ],[
>> @@ -213,6 +213,123 @@
>>
>> ])
>>
>> +
>> +dnl use: EVAS_CHECK_ENGINE_DEP_GL_XCB(engine, simple, want_static[,
>> ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
>> +
>> +AC_DEFUN([EVAS_CHECK_ENGINE_DEP_GL_XCB],
>> +[
>> +
>> +evas_engine_[]$1[]_cflags=""
>> +evas_engine_[]$1[]_libs=""
>> +
>> +AC_PATH_X
>> +AC_PATH_XTRA
>> +
>> +AC_CHECK_HEADER([GL/gl.h],
>> + [have_dep="yes"],
>> + [have_dep="no"],
>> + [
>> +#include
>> +#include
>> +#include
>> + ])
>> +
>> +gl_pt_lib="";
>> +have_gl_pt="no"
>> +AC_CHECK_LIB([pthread], [pthread_create], [have_gl_pt="yes"],
>> [have_gl_pt="no"])
>> +if test "x$have_gl_pt" = "xyes" ; then
>> + gl_pt_lib=" -lpthread"
>> +fi
>> +
>> +if test "x${have_dep}" = "xyes" ; then
>> + AC_CHECK_LIB([X11], [XCreateColormap], [have_dep="yes"], [have_dep="no"])
>> +fi
>> +
>> +if test "x${have_dep}" = "xyes" ; then
>> + AC_CHECK_LIB([Xrender], [XRenderCreatePicture], [have_dep="yes"],
>> [have_dep="no"])
>> +fi
>> +
>> +if test "x${have_dep}" = "xyes" ; then
>> + AC_CHECK_LIB([GL], [glXCreateContext], [have_dep="yes"],
>> [have_dep="no"], -lX11 -lXext -lXrender -lm $gl_pt_lib)
>> +fi
>> +
>> +PKG_CHECK_MODULES([XCB_GL],
>> + [x11-xcb xcb xcb-aux xcb-glx xcb-render xcb-renderutil],
>> + [
>> +have_dep="yes"
>> +requirement="x11-xcb xcb xcb-aux xcb-glx xcb-render xcb-renderutil"
>> +evas_engine_[]$1[]_cflags="${XCB_GL_CFLAGS}"
>> +evas_engine_[]$1[]_libs="${XCB_GL_LIBS}"
>> + ],[
>> +have_dep="no"
>> + ]
>> +)
>> +
>> +if test "x$gl_flavor_gles" = "xyes" ; then
>> + have_dep=no
>> +fi
>> +
>> +if test "x${have_dep}" = "xyes" ; then
>> + PKG_CHECK_MODULES([GL_EET], [eet>= 1.4.0], [have_dep="yes"],
>> [have_dep="no"])
>> + if test "x${have_dep}" = "xyes" ; then
>> + if test "x$2" = "xyes" ; then
>> + x_libs="${x_libs} -lX11 -lXext -lXrender"
>> + else
>> + x_dir=${x_dir:-/usr/X11R6}
>> + x_cflags=${x_cflags:--I${x_includes:-$x_dir/include}}
>> + x_libs="${x_libs:--L${x_libraries:-$x_dir/lib}} -lX11 -lXext
>> -lXrender"
>> + fi
>> + evas_engine_[]$1[]_cflags="-I/usr/include ${XCB_GL_CFLAGS} ${x_cflags}"
>> + evas_engine_[]$1[]_libs="${XCB_GL_LIBS} ${x_libs} -lGL $gl_pt_lib"
>> + evas_engine_gl_common_libs="-lGL $gl_pt_lib"
>> + fi
>> +else
>> + if test "x$2" = "xyes" ; then
>> + x_libs="${x_libs} -lX11 -lXext -lXrender"
>> + else
>> + x_dir=${x_dir:-/usr/X11R6}
>> + x_cflags=${x_cflags:--I${x_includes:-$x_dir/include}}
>> + x_libs="${x_libs:--L${x_libraries:-$x_dir/lib}} -lX11 -lXext
>> -lXrender"
>> + fi
>> + AC_CHECK_HEADER([GLES2/gl2.h],
>> + [have_egl="yes"],
>> + [have_egl="no"],
>> + [
>> +#include
>> +#include
>> +#include
>> + ])
>> + if test "x${have_egl}" = "xyes" ; then
>> + AC_CHECK_LIB(GLESv2, glTexImage2D, [have_glesv2="yes"], , -lEGL
>> ${x_libs} -lm $gl_pt_lib)
>> + if test "x${have_glesv2}" = "xyes" ; then
>> + PKG_CHECK_MODULES([GL_EET], [eet>= 1.4.0], [have_dep="yes"],
>> [have_dep="no"])
>> + if test "x${have_dep}" = "xyes" ; then
>> +evas_engine_[]$1[]_cflags="${XCB_GL_CFLAGS} ${x_cflags}"
>> +evas_engine_[]$1[]_libs="${XCB_GL_LIBS} ${x_libs} -lGLESv2
>> -lEGL -lm $gl_pt_lib"
>> +evas_engine_gl_common_libs="-lGLESv2 -lm $gl_pt_lib"
>> +have_dep="yes"
>> +
Re: [E-devel] E SVN: devilhorns trunk/evas/m4
On Fri, 8 Jul 2011, Christopher Michael wrote:
> Why ?
it's most of the time not async and they usually do much more than we
need. Why do you need it for ?
Vincent
>
> dh
>
> On 07/08/11 11:10, Vincent Torri wrote:
>>
>> using xcb-aux is a bad idea
>>
>> Vincent
>>
>> On Thu, 7 Jul 2011, Enlightenment SVN wrote:
>>
>>> Log:
>>> Evas: Fix up the check_engine macros for xcb engine& xlib changes.
>>>
>>>
>>>
>>> Author: devilhorns
>>> Date: 2011-07-07 17:18:22 -0700 (Thu, 07 Jul 2011)
>>> New Revision: 61137
>>> Trac: http://trac.enlightenment.org/e/changeset/61137
>>>
>>> Modified:
>>> trunk/evas/m4/evas_check_engine.m4
>>>
>>> Modified: trunk/evas/m4/evas_check_engine.m4
>>> ===
>>> --- trunk/evas/m4/evas_check_engine.m4 2011-07-08 00:17:52 UTC (rev
>>> 61136)
>>> +++ trunk/evas/m4/evas_check_engine.m4 2011-07-08 00:18:22 UTC (rev
>>> 61137)
>>> @@ -64,9 +64,9 @@
>>>
>>> ])
>>>
>>> -dnl use: EVAS_CHECK_ENGINE_DEP_GL_X11(engine, simple, want_static[,
>>> ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
>>> +dnl use: EVAS_CHECK_ENGINE_DEP_GL_XLIB(engine, simple, want_static[,
>>> ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
>>>
>>> -AC_DEFUN([EVAS_CHECK_ENGINE_DEP_GL_X11],
>>> +AC_DEFUN([EVAS_CHECK_ENGINE_DEP_GL_XLIB],
>>> [
>>>
>>> evas_engine_[]$1[]_cflags=""
>>> @@ -187,10 +187,10 @@
>>> evas_engine_[]$1[]_libs=""
>>>
>>> PKG_CHECK_MODULES([XCB],
>>> - [xcb xcb-shm xcb-image>= 0.2.1 pixman-1],
>>> + [xcb xcb-shm xcb-image>= 0.2.1 xcb-aux pixman-1],
>>> [
>>> have_dep="yes"
>>> -requirement="xcb xcb-shm xcb-image pixman-1"
>>> +requirement="xcb xcb-shm xcb-image xcb-aux pixman-1"
>>> evas_engine_[]$1[]_cflags="${XCB_CFLAGS}"
>>> evas_engine_[]$1[]_libs="${XCB_LIBS}"
>>> ],[
>>> @@ -213,6 +213,123 @@
>>>
>>> ])
>>>
>>> +
>>> +dnl use: EVAS_CHECK_ENGINE_DEP_GL_XCB(engine, simple, want_static[,
>>> ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
>>> +
>>> +AC_DEFUN([EVAS_CHECK_ENGINE_DEP_GL_XCB],
>>> +[
>>> +
>>> +evas_engine_[]$1[]_cflags=""
>>> +evas_engine_[]$1[]_libs=""
>>> +
>>> +AC_PATH_X
>>> +AC_PATH_XTRA
>>> +
>>> +AC_CHECK_HEADER([GL/gl.h],
>>> + [have_dep="yes"],
>>> + [have_dep="no"],
>>> + [
>>> +#include
>>> +#include
>>> +#include
>>> + ])
>>> +
>>> +gl_pt_lib="";
>>> +have_gl_pt="no"
>>> +AC_CHECK_LIB([pthread], [pthread_create], [have_gl_pt="yes"],
>>> [have_gl_pt="no"])
>>> +if test "x$have_gl_pt" = "xyes" ; then
>>> + gl_pt_lib=" -lpthread"
>>> +fi
>>> +
>>> +if test "x${have_dep}" = "xyes" ; then
>>> + AC_CHECK_LIB([X11], [XCreateColormap], [have_dep="yes"],
>>> [have_dep="no"])
>>> +fi
>>> +
>>> +if test "x${have_dep}" = "xyes" ; then
>>> + AC_CHECK_LIB([Xrender], [XRenderCreatePicture], [have_dep="yes"],
>>> [have_dep="no"])
>>> +fi
>>> +
>>> +if test "x${have_dep}" = "xyes" ; then
>>> + AC_CHECK_LIB([GL], [glXCreateContext], [have_dep="yes"],
>>> [have_dep="no"], -lX11 -lXext -lXrender -lm $gl_pt_lib)
>>> +fi
>>> +
>>> +PKG_CHECK_MODULES([XCB_GL],
>>> + [x11-xcb xcb xcb-aux xcb-glx xcb-render xcb-renderutil],
>>> + [
>>> +have_dep="yes"
>>> +requirement="x11-xcb xcb xcb-aux xcb-glx xcb-render xcb-renderutil"
>>> +evas_engine_[]$1[]_cflags="${XCB_GL_CFLAGS}"
>>> +evas_engine_[]$1[]_libs="${XCB_GL_LIBS}"
>>> + ],[
>>> +have_dep="no"
>>> + ]
>>> +)
>>> +
>>> +if test "x$gl_flavor_gles" = "xyes" ; then
>>> + have_dep=no
>>> +fi
>>> +
>>> +if test "x${have_dep}" = "xyes" ; then
>>> + PKG_CHECK_MODULES([GL_EET], [eet>= 1.4.0], [have_dep="yes"],
>>> [have_dep="no"])
>>> + if test "x${have_dep}" = "xyes" ; then
>>> + if test "x$2" = "xyes" ; then
>>> + x_libs="${x_libs} -lX11 -lXext -lXrender"
>>> + else
>>> + x_dir=${x_dir:-/usr/X11R6}
>>> + x_cflags=${x_cflags:--I${x_includes:-$x_dir/include}}
>>> + x_libs="${x_libs:--L${x_libraries:-$x_dir/lib}} -lX11 -lXext
>>> -lXrender"
>>> + fi
>>> + evas_engine_[]$1[]_cflags="-I/usr/include ${XCB_GL_CFLAGS} ${x_cflags}"
>>> + evas_engine_[]$1[]_libs="${XCB_GL_LIBS} ${x_libs} -lGL $gl_pt_lib"
>>> + evas_engine_gl_common_libs="-lGL $gl_pt_lib"
>>> + fi
>>> +else
>>> + if test "x$2" = "xyes" ; then
>>> + x_libs="${x_libs} -lX11 -lXext -lXrender"
>>> + else
>>> + x_dir=${x_dir:-/usr/X11R6}
>>> + x_cflags=${x_cflags:--I${x_includes:-$x_dir/include}}
>>> + x_libs="${x_libs:--L${x_libraries:-$x_dir/lib}} -lX11 -lXext
>>> -lXrender"
>>> + fi
>>> + AC_CHECK_HEADER([GLES2/gl2.h],
>>> + [have_egl="yes"],
>>> + [have_egl="no"],
>>> + [
>>> +#include
>>> +#include
>>> +#include
>>> + ])
>>> + if test "x${have_egl}" = "xyes" ; then
>>> + AC_CHECK_LIB(GLESv2, glTexImage2D, [have_glesv2="yes"], , -lEGL
>>> ${x_libs} -lm $gl_pt_lib)
>>> + if test "x${have_glesv2}" = "xyes" ; then
>>> + PKG_CHECK_MODULES([GL_EET], [eet>= 1.4.0], [have_dep="yes"],
>>> [have_dep="no"])
>>>
Re: [E-devel] E SVN: devilhorns trunk/evas/m4
On 07/08/11 22:48, Vincent Torri wrote:
>
>
> On Fri, 8 Jul 2011, Christopher Michael wrote:
>
>> Why ?
>
> it's most of the time not async and they usually do much more than we
> need. Why do you need it for ?
>
In Evas, it's only use is for one of the utility functios
(xcb_aux_find_visual_by_id).
dh
> Vincent
>
>>
>> dh
>>
>> On 07/08/11 11:10, Vincent Torri wrote:
>>>
>>> using xcb-aux is a bad idea
>>>
>>> Vincent
>>>
>>> On Thu, 7 Jul 2011, Enlightenment SVN wrote:
>>>
Log:
Evas: Fix up the check_engine macros for xcb engine& xlib changes.
Author: devilhorns
Date: 2011-07-07 17:18:22 -0700 (Thu, 07 Jul 2011)
New Revision: 61137
Trac: http://trac.enlightenment.org/e/changeset/61137
Modified:
trunk/evas/m4/evas_check_engine.m4
Modified: trunk/evas/m4/evas_check_engine.m4
===
--- trunk/evas/m4/evas_check_engine.m4 2011-07-08 00:17:52 UTC (rev
61136)
+++ trunk/evas/m4/evas_check_engine.m4 2011-07-08 00:18:22 UTC (rev
61137)
@@ -64,9 +64,9 @@
])
-dnl use: EVAS_CHECK_ENGINE_DEP_GL_X11(engine, simple, want_static[,
ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
+dnl use: EVAS_CHECK_ENGINE_DEP_GL_XLIB(engine, simple,
want_static[, ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
-AC_DEFUN([EVAS_CHECK_ENGINE_DEP_GL_X11],
+AC_DEFUN([EVAS_CHECK_ENGINE_DEP_GL_XLIB],
[
evas_engine_[]$1[]_cflags=""
@@ -187,10 +187,10 @@
evas_engine_[]$1[]_libs=""
PKG_CHECK_MODULES([XCB],
- [xcb xcb-shm xcb-image>= 0.2.1 pixman-1],
+ [xcb xcb-shm xcb-image>= 0.2.1 xcb-aux pixman-1],
[
have_dep="yes"
- requirement="xcb xcb-shm xcb-image pixman-1"
+ requirement="xcb xcb-shm xcb-image xcb-aux pixman-1"
evas_engine_[]$1[]_cflags="${XCB_CFLAGS}"
evas_engine_[]$1[]_libs="${XCB_LIBS}"
],[
@@ -213,6 +213,123 @@
])
+
+dnl use: EVAS_CHECK_ENGINE_DEP_GL_XCB(engine, simple, want_static[,
ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
+
+AC_DEFUN([EVAS_CHECK_ENGINE_DEP_GL_XCB],
+[
+
+evas_engine_[]$1[]_cflags=""
+evas_engine_[]$1[]_libs=""
+
+AC_PATH_X
+AC_PATH_XTRA
+
+AC_CHECK_HEADER([GL/gl.h],
+ [have_dep="yes"],
+ [have_dep="no"],
+ [
+#include
+#include
+#include
+ ])
+
+gl_pt_lib="";
+have_gl_pt="no"
+AC_CHECK_LIB([pthread], [pthread_create], [have_gl_pt="yes"],
[have_gl_pt="no"])
+if test "x$have_gl_pt" = "xyes" ; then
+ gl_pt_lib=" -lpthread"
+fi
+
+if test "x${have_dep}" = "xyes" ; then
+ AC_CHECK_LIB([X11], [XCreateColormap], [have_dep="yes"],
[have_dep="no"])
+fi
+
+if test "x${have_dep}" = "xyes" ; then
+ AC_CHECK_LIB([Xrender], [XRenderCreatePicture], [have_dep="yes"],
[have_dep="no"])
+fi
+
+if test "x${have_dep}" = "xyes" ; then
+ AC_CHECK_LIB([GL], [glXCreateContext], [have_dep="yes"],
[have_dep="no"], -lX11 -lXext -lXrender -lm $gl_pt_lib)
+fi
+
+PKG_CHECK_MODULES([XCB_GL],
+ [x11-xcb xcb xcb-aux xcb-glx xcb-render xcb-renderutil],
+ [
+ have_dep="yes"
+ requirement="x11-xcb xcb xcb-aux xcb-glx xcb-render xcb-renderutil"
+ evas_engine_[]$1[]_cflags="${XCB_GL_CFLAGS}"
+ evas_engine_[]$1[]_libs="${XCB_GL_LIBS}"
+ ],[
+ have_dep="no"
+ ]
+)
+
+if test "x$gl_flavor_gles" = "xyes" ; then
+ have_dep=no
+fi
+
+if test "x${have_dep}" = "xyes" ; then
+ PKG_CHECK_MODULES([GL_EET], [eet>= 1.4.0], [have_dep="yes"],
[have_dep="no"])
+ if test "x${have_dep}" = "xyes" ; then
+ if test "x$2" = "xyes" ; then
+ x_libs="${x_libs} -lX11 -lXext -lXrender"
+ else
+ x_dir=${x_dir:-/usr/X11R6}
+ x_cflags=${x_cflags:--I${x_includes:-$x_dir/include}}
+ x_libs="${x_libs:--L${x_libraries:-$x_dir/lib}} -lX11 -lXext
-lXrender"
+ fi
+ evas_engine_[]$1[]_cflags="-I/usr/include ${XCB_GL_CFLAGS}
${x_cflags}"
+ evas_engine_[]$1[]_libs="${XCB_GL_LIBS} ${x_libs} -lGL $gl_pt_lib"
+ evas_engine_gl_common_libs="-lGL $gl_pt_lib"
+ fi
+else
+ if test "x$2" = "xyes" ; then
+ x_libs="${x_libs} -lX11 -lXext -lXrender"
+ else
+ x_dir=${x_dir:-/usr/X11R6}
+ x_cflags=${x_cflags:--I${x_includes:-$x_dir/include}}
+ x_libs="${x_libs:--L${x_libraries:-$x_dir/lib}} -lX11 -lXext
-lXrender"
+ fi
+ AC_CHECK_HEADER([GLES2/gl2.h],
+ [have_egl="yes"],
+ [have_egl="no"],
+ [
+#include
+#include
+#include
+ ])
+ if test "x${have_egl}" = "xyes" ; then
+ AC_CHECK_LIB(GLESv2, glTexImage2D, [have_glesv2="yes"], , -lEGL
${x_libs} -lm $gl_pt_lib)
+ if test "x${have_glesv2}" = "xyes" ; then
+ PKG_CHECK_MODULES([GL_
Re: [E-devel] E SVN: devilhorns trunk/evas/m4
On Sat, 9 Jul 2011, Christopher Michael wrote:
> On 07/08/11 22:48, Vincent Torri wrote:
>>
>>
>> On Fri, 8 Jul 2011, Christopher Michael wrote:
>>
>>> Why ?
>>
>> it's most of the time not async and they usually do much more than we
>> need. Why do you need it for ?
>>
> In Evas, it's only use is for one of the utility functios
> (xcb_aux_find_visual_by_id).
so take the code of that function instead of adding one dependency.
Vincent
>
> dh
>
>> Vincent
>>
>>>
>>> dh
>>>
>>> On 07/08/11 11:10, Vincent Torri wrote:
using xcb-aux is a bad idea
Vincent
On Thu, 7 Jul 2011, Enlightenment SVN wrote:
> Log:
> Evas: Fix up the check_engine macros for xcb engine& xlib changes.
>
>
>
> Author: devilhorns
> Date: 2011-07-07 17:18:22 -0700 (Thu, 07 Jul 2011)
> New Revision: 61137
> Trac: http://trac.enlightenment.org/e/changeset/61137
>
> Modified:
> trunk/evas/m4/evas_check_engine.m4
>
> Modified: trunk/evas/m4/evas_check_engine.m4
> ===
> --- trunk/evas/m4/evas_check_engine.m4 2011-07-08 00:17:52 UTC (rev
> 61136)
> +++ trunk/evas/m4/evas_check_engine.m4 2011-07-08 00:18:22 UTC (rev
> 61137)
> @@ -64,9 +64,9 @@
>
> ])
>
> -dnl use: EVAS_CHECK_ENGINE_DEP_GL_X11(engine, simple, want_static[,
> ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
> +dnl use: EVAS_CHECK_ENGINE_DEP_GL_XLIB(engine, simple,
> want_static[, ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
>
> -AC_DEFUN([EVAS_CHECK_ENGINE_DEP_GL_X11],
> +AC_DEFUN([EVAS_CHECK_ENGINE_DEP_GL_XLIB],
> [
>
> evas_engine_[]$1[]_cflags=""
> @@ -187,10 +187,10 @@
> evas_engine_[]$1[]_libs=""
>
> PKG_CHECK_MODULES([XCB],
> - [xcb xcb-shm xcb-image>= 0.2.1 pixman-1],
> + [xcb xcb-shm xcb-image>= 0.2.1 xcb-aux pixman-1],
> [
> have_dep="yes"
> - requirement="xcb xcb-shm xcb-image pixman-1"
> + requirement="xcb xcb-shm xcb-image xcb-aux pixman-1"
> evas_engine_[]$1[]_cflags="${XCB_CFLAGS}"
> evas_engine_[]$1[]_libs="${XCB_LIBS}"
> ],[
> @@ -213,6 +213,123 @@
>
> ])
>
> +
> +dnl use: EVAS_CHECK_ENGINE_DEP_GL_XCB(engine, simple, want_static[,
> ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
> +
> +AC_DEFUN([EVAS_CHECK_ENGINE_DEP_GL_XCB],
> +[
> +
> +evas_engine_[]$1[]_cflags=""
> +evas_engine_[]$1[]_libs=""
> +
> +AC_PATH_X
> +AC_PATH_XTRA
> +
> +AC_CHECK_HEADER([GL/gl.h],
> + [have_dep="yes"],
> + [have_dep="no"],
> + [
> +#include
> +#include
> +#include
> + ])
> +
> +gl_pt_lib="";
> +have_gl_pt="no"
> +AC_CHECK_LIB([pthread], [pthread_create], [have_gl_pt="yes"],
> [have_gl_pt="no"])
> +if test "x$have_gl_pt" = "xyes" ; then
> + gl_pt_lib=" -lpthread"
> +fi
> +
> +if test "x${have_dep}" = "xyes" ; then
> + AC_CHECK_LIB([X11], [XCreateColormap], [have_dep="yes"],
> [have_dep="no"])
> +fi
> +
> +if test "x${have_dep}" = "xyes" ; then
> + AC_CHECK_LIB([Xrender], [XRenderCreatePicture], [have_dep="yes"],
> [have_dep="no"])
> +fi
> +
> +if test "x${have_dep}" = "xyes" ; then
> + AC_CHECK_LIB([GL], [glXCreateContext], [have_dep="yes"],
> [have_dep="no"], -lX11 -lXext -lXrender -lm $gl_pt_lib)
> +fi
> +
> +PKG_CHECK_MODULES([XCB_GL],
> + [x11-xcb xcb xcb-aux xcb-glx xcb-render xcb-renderutil],
> + [
> + have_dep="yes"
> + requirement="x11-xcb xcb xcb-aux xcb-glx xcb-render xcb-renderutil"
> + evas_engine_[]$1[]_cflags="${XCB_GL_CFLAGS}"
> + evas_engine_[]$1[]_libs="${XCB_GL_LIBS}"
> + ],[
> + have_dep="no"
> + ]
> +)
> +
> +if test "x$gl_flavor_gles" = "xyes" ; then
> + have_dep=no
> +fi
> +
> +if test "x${have_dep}" = "xyes" ; then
> + PKG_CHECK_MODULES([GL_EET], [eet>= 1.4.0], [have_dep="yes"],
> [have_dep="no"])
> + if test "x${have_dep}" = "xyes" ; then
> + if test "x$2" = "xyes" ; then
> + x_libs="${x_libs} -lX11 -lXext -lXrender"
> + else
> + x_dir=${x_dir:-/usr/X11R6}
> + x_cflags=${x_cflags:--I${x_includes:-$x_dir/include}}
> + x_libs="${x_libs:--L${x_libraries:-$x_dir/lib}} -lX11 -lXext
> -lXrender"
> + fi
> + evas_engine_[]$1[]_cflags="-I/usr/include ${XCB_GL_CFLAGS}
> ${x_cflags}"
> + evas_engine_[]$1[]_libs="${XCB_GL_LIBS} ${x_libs} -lGL $gl_pt_lib"
> + evas_engine_gl_common_libs="-lGL $gl_pt_lib"
> + fi
> +else
> + if test "x$2" = "xyes" ; then
> + x_libs="${x_libs} -lX11 -lXext -lXrender"
> + else
> + x_dir=${x_dir:-/usr/X11R6}
> + x_cflags=${x_cflags:--I${x_includes:-$x_dir/include}}
> + x_libs="${x_libs:--L${x_libraries:-$x_dir/lib}} -lX11 -lXext
> -lXrender"
> + fi
> + AC_CHECK_HEADER([GLES2/gl2.h],
> + [have_eg
Re: [E-devel] E SVN: devilhorns trunk/evas/m4
On 07/09/11 09:04, Vincent Torri wrote:
>
>
> On Sat, 9 Jul 2011, Christopher Michael wrote:
>
>> On 07/08/11 22:48, Vincent Torri wrote:
>>>
>>>
>>> On Fri, 8 Jul 2011, Christopher Michael wrote:
>>>
Why ?
>>>
>>> it's most of the time not async and they usually do much more than we
>>> need. Why do you need it for ?
>>>
>> In Evas, it's only use is for one of the utility functios
>> (xcb_aux_find_visual_by_id).
>
> so take the code of that function instead of adding one dependency.
>
> Vincent
>
Yea, suppose we could ;)
dh
>>
>> dh
>>
>>> Vincent
>>>
dh
On 07/08/11 11:10, Vincent Torri wrote:
>
> using xcb-aux is a bad idea
>
> Vincent
>
> On Thu, 7 Jul 2011, Enlightenment SVN wrote:
>
>> Log:
>> Evas: Fix up the check_engine macros for xcb engine& xlib changes.
>>
>>
>>
>> Author: devilhorns
>> Date: 2011-07-07 17:18:22 -0700 (Thu, 07 Jul 2011)
>> New Revision: 61137
>> Trac: http://trac.enlightenment.org/e/changeset/61137
>>
>> Modified:
>> trunk/evas/m4/evas_check_engine.m4
>>
>> Modified: trunk/evas/m4/evas_check_engine.m4
>> ===
>> --- trunk/evas/m4/evas_check_engine.m4 2011-07-08 00:17:52 UTC (rev
>> 61136)
>> +++ trunk/evas/m4/evas_check_engine.m4 2011-07-08 00:18:22 UTC (rev
>> 61137)
>> @@ -64,9 +64,9 @@
>>
>> ])
>>
>> -dnl use: EVAS_CHECK_ENGINE_DEP_GL_X11(engine, simple, want_static[,
>> ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
>> +dnl use: EVAS_CHECK_ENGINE_DEP_GL_XLIB(engine, simple,
>> want_static[, ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
>>
>> -AC_DEFUN([EVAS_CHECK_ENGINE_DEP_GL_X11],
>> +AC_DEFUN([EVAS_CHECK_ENGINE_DEP_GL_XLIB],
>> [
>>
>> evas_engine_[]$1[]_cflags=""
>> @@ -187,10 +187,10 @@
>> evas_engine_[]$1[]_libs=""
>>
>> PKG_CHECK_MODULES([XCB],
>> - [xcb xcb-shm xcb-image>= 0.2.1 pixman-1],
>> + [xcb xcb-shm xcb-image>= 0.2.1 xcb-aux pixman-1],
>> [
>> have_dep="yes"
>> - requirement="xcb xcb-shm xcb-image pixman-1"
>> + requirement="xcb xcb-shm xcb-image xcb-aux pixman-1"
>> evas_engine_[]$1[]_cflags="${XCB_CFLAGS}"
>> evas_engine_[]$1[]_libs="${XCB_LIBS}"
>> ],[
>> @@ -213,6 +213,123 @@
>>
>> ])
>>
>> +
>> +dnl use: EVAS_CHECK_ENGINE_DEP_GL_XCB(engine, simple, want_static[,
>> ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
>> +
>> +AC_DEFUN([EVAS_CHECK_ENGINE_DEP_GL_XCB],
>> +[
>> +
>> +evas_engine_[]$1[]_cflags=""
>> +evas_engine_[]$1[]_libs=""
>> +
>> +AC_PATH_X
>> +AC_PATH_XTRA
>> +
>> +AC_CHECK_HEADER([GL/gl.h],
>> + [have_dep="yes"],
>> + [have_dep="no"],
>> + [
>> +#include
>> +#include
>> +#include
>> + ])
>> +
>> +gl_pt_lib="";
>> +have_gl_pt="no"
>> +AC_CHECK_LIB([pthread], [pthread_create], [have_gl_pt="yes"],
>> [have_gl_pt="no"])
>> +if test "x$have_gl_pt" = "xyes" ; then
>> + gl_pt_lib=" -lpthread"
>> +fi
>> +
>> +if test "x${have_dep}" = "xyes" ; then
>> + AC_CHECK_LIB([X11], [XCreateColormap], [have_dep="yes"],
>> [have_dep="no"])
>> +fi
>> +
>> +if test "x${have_dep}" = "xyes" ; then
>> + AC_CHECK_LIB([Xrender], [XRenderCreatePicture], [have_dep="yes"],
>> [have_dep="no"])
>> +fi
>> +
>> +if test "x${have_dep}" = "xyes" ; then
>> + AC_CHECK_LIB([GL], [glXCreateContext], [have_dep="yes"],
>> [have_dep="no"], -lX11 -lXext -lXrender -lm $gl_pt_lib)
>> +fi
>> +
>> +PKG_CHECK_MODULES([XCB_GL],
>> + [x11-xcb xcb xcb-aux xcb-glx xcb-render xcb-renderutil],
>> + [
>> + have_dep="yes"
>> + requirement="x11-xcb xcb xcb-aux xcb-glx xcb-render xcb-renderutil"
>> + evas_engine_[]$1[]_cflags="${XCB_GL_CFLAGS}"
>> + evas_engine_[]$1[]_libs="${XCB_GL_LIBS}"
>> + ],[
>> + have_dep="no"
>> + ]
>> +)
>> +
>> +if test "x$gl_flavor_gles" = "xyes" ; then
>> + have_dep=no
>> +fi
>> +
>> +if test "x${have_dep}" = "xyes" ; then
>> + PKG_CHECK_MODULES([GL_EET], [eet>= 1.4.0], [have_dep="yes"],
>> [have_dep="no"])
>> + if test "x${have_dep}" = "xyes" ; then
>> + if test "x$2" = "xyes" ; then
>> + x_libs="${x_libs} -lX11 -lXext -lXrender"
>> + else
>> + x_dir=${x_dir:-/usr/X11R6}
>> + x_cflags=${x_cflags:--I${x_includes:-$x_dir/include}}
>> + x_libs="${x_libs:--L${x_libraries:-$x_dir/lib}} -lX11 -lXext
>> -lXrender"
>> + fi
>> + evas_engine_[]$1[]_cflags="-I/usr/include ${XCB_GL_CFLAGS}
>> ${x_cflags}"
>> + evas_engine_[]$1[]_libs="${XCB_GL_LIBS} ${x_libs} -lGL $gl_pt_lib"
>> + evas_engine_gl_common_libs="-lGL $gl_pt_lib"
>> + fi
>> +else
>> + if test "x$2" = "xyes" ; then
>> + x_libs="${x_libs} -lX11 -lXext -lXrender"
>> + else
>> + x_dir=${x_dir:-/usr/X11
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib
On Mon, 17 Sep 2012 04:01:20 -0700 "Enlightenment SVN" wrote: > Log: > Evas: Fix doxy grammar (never heard of anti-clock-wise) ;) That will be coz it's counterclockwise in USA, but anticlockwise in other places. B-) /me thinks he should start "fixing" all references to "color" to the "correct" spelling - "colour". ;-P -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib
HAHAHAHAHAHA -Regards, Hermet- -Original Message- From: "Enlightenment SVN" To: ; Cc: Sent: 2012-09-17 (월) 20:01:20 Subject: E SVN: devilhorns trunk/evas/src/lib Log: Evas: Fix doxy grammar (never heard of anti-clock-wise) ;) Author: devilhorns Date: 2012-09-17 04:01:20 -0700 (Mon, 17 Sep 2012) New Revision: 76754 Trac: http://trac.enlightenment.org/e/changeset/76754 Modified: trunk/evas/src/lib/Evas.h Modified: trunk/evas/src/lib/Evas.h === --- trunk/evas/src/lib/Evas.h2012-09-17 10:33:42 UTC (rev 76753) +++ trunk/evas/src/lib/Evas.h2012-09-17 11:01:20 UTC (rev 76754) @@ -5059,7 +5059,7 @@ * * This sets the fixed point's coordinate in the map. Note that points * describe the outline of a quadrangle and are ordered either clockwise - * or anti-clock-wise. It is suggested to keep your quadrangles concave and + * or counter clock-wise. It is suggested to keep your quadrangles concave and * non-complex, though these polygon modes may work, they may not render * a desired set of output. The quadrangle will use points 0 and 1 , 1 and 2, * 2 and 3, and 3 and 0 to describe the edges of the quadrangle. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-svn mailing list enlightenment-...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-svn -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/bin
On Thu, 26 May 2011, Enlightenment SVN wrote:
> Log:
> Evas: Fix shadow declaration of 'i' variable.
>
>
>
> Author: devilhorns
> Date: 2011-05-26 18:50:10 -0700 (Thu, 26 May 2011)
> New Revision: 59716
> Trac: http://trac.enlightenment.org/e/changeset/59716
>
> Modified:
> trunk/evas/src/bin/evas_cserve_tool.c
>
> Modified: trunk/evas/src/bin/evas_cserve_tool.c
> ===
> --- trunk/evas/src/bin/evas_cserve_tool.c 2011-05-27 01:47:58 UTC (rev
> 59715)
> +++ trunk/evas/src/bin/evas_cserve_tool.c 2011-05-27 01:50:10 UTC (rev
> 59716)
> @@ -10,7 +10,7 @@
> main(int argc, char **argv)
> {
>int i;
> -
> +
>evas_init();
>if (!evas_cserve_init())
> {
> @@ -86,8 +86,8 @@
> {
> Op_Getinfo_Reply *info;
> unsigned char *p;
> - int i, j;
> -
> + int h, j;
> +
> info = evas_cserve_raw_info_get();
> if (!info)
>{
> @@ -102,7 +102,7 @@
> printf("cache_memory: %i Kb\n", info->cached.mem_total);
> p = (unsigned char *)info;
> p += sizeof(Op_Getinfo_Reply);
> - for (i = 0; i < j; i++)
> + for (h = 0; h < j; h++)
actually, why not just using i again without the declaration of the
sub-block ? i is certainly just used for the 'for' loop
Vincent
>{
> Op_Getinfo_Item it;
> char *file, *key, buf[512];
> @@ -111,7 +111,7 @@
> memcpy(&it, p, sizeof(Op_Getinfo_Item));
> file = (char*) (p + sizeof(Op_Getinfo_Item));
> key = file + strlen(file) + 1;
> - printf("-IMAGE- [#%i]\n", i);
> + printf("-IMAGE- [#%i]\n", h);
> printf(" file : %s\n", file);
> printf(" key: %s\n", key);
> printf(" size : %i x %i\n", it.w, it.h);
>
>
> --
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
>
--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/bin
On 05/27/2011 12:17 AM, Vincent Torri wrote:
>
>
> On Thu, 26 May 2011, Enlightenment SVN wrote:
>
>> Log:
>> Evas: Fix shadow declaration of 'i' variable.
>>
>>
>>
>> Author: devilhorns
>> Date: 2011-05-26 18:50:10 -0700 (Thu, 26 May 2011)
>> New Revision: 59716
>> Trac: http://trac.enlightenment.org/e/changeset/59716
>>
>> Modified:
>> trunk/evas/src/bin/evas_cserve_tool.c
>>
>> Modified: trunk/evas/src/bin/evas_cserve_tool.c
>> ===
>> --- trunk/evas/src/bin/evas_cserve_tool.c2011-05-27 01:47:58 UTC (rev
>> 59715)
>> +++ trunk/evas/src/bin/evas_cserve_tool.c2011-05-27 01:50:10 UTC (rev
>> 59716)
>> @@ -10,7 +10,7 @@
>> main(int argc, char **argv)
>> {
>> int i;
>> -
>> +
>> evas_init();
>> if (!evas_cserve_init())
>> {
>> @@ -86,8 +86,8 @@
>>{
>> Op_Getinfo_Reply *info;
>> unsigned char *p;
>> - int i, j;
>> -
>> + int h, j;
>> +
>> info = evas_cserve_raw_info_get();
>> if (!info)
>> {
>> @@ -102,7 +102,7 @@
>> printf("cache_memory: %i Kb\n", info->cached.mem_total);
>> p = (unsigned char *)info;
>> p += sizeof(Op_Getinfo_Reply);
>> - for (i = 0; i< j; i++)
>> + for (h = 0; h< j; h++)
>
> actually, why not just using i again without the declaration of the
> sub-block ? i is certainly just used for the 'for' loop
>
> Vincent
>
Yea, suppose it could have been done like that also...but in all
honesty, I was just handling the compiler warnings and not really
'reading' the code as I was pressed for time, so it was just a 'quick
fix' that 'should not break anything'.
If it's something that bugs you, feel free to fix ;)
dh
>> {
>>Op_Getinfo_Item it;
>>char *file, *key, buf[512];
>> @@ -111,7 +111,7 @@
>>memcpy(&it, p, sizeof(Op_Getinfo_Item));
>>file = (char*) (p + sizeof(Op_Getinfo_Item));
>>key = file + strlen(file) + 1;
>> - printf("-IMAGE- [#%i]\n", i);
>> + printf("-IMAGE- [#%i]\n", h);
>>printf(" file : %s\n", file);
>>printf(" key: %s\n", key);
>>printf(" size : %i x %i\n", it.w, it.h);
>>
>>
--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib
doc, @since, ChangeLog, NEWS how is it possible that someone still forget about that Vincent On Tue, Dec 27, 2011 at 12:08 AM, Enlightenment SVN wrote: > Log: > Evas: Add functions to get/set if an object is a 'frame object'. > > > > Author: devilhorns > Date: 2011-12-26 15:08:17 -0800 (Mon, 26 Dec 2011) > New Revision: 66535 > Trac: http://trac.enlightenment.org/e/changeset/66535 > > Modified: > trunk/evas/src/lib/Evas.h > > Modified: trunk/evas/src/lib/Evas.h > === > --- trunk/evas/src/lib/Evas.h 2011-12-26 23:07:52 UTC (rev 66534) > +++ trunk/evas/src/lib/Evas.h 2011-12-26 23:08:17 UTC (rev 66535) > @@ -9050,6 +9050,9 @@ > * @} > */ > > +EAPI void evas_object_is_frame_object_set(Evas_Object *obj, > Eina_Bool is_frame); > +EAPI Eina_Bool evas_object_is_frame_object_get(Evas_Object *obj); > + > /** > * @defgroup Evas_Smart_Group Smart Functions > * > > > -- > Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. Create > new or port existing apps to sell to consumers worldwide. Explore the > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join > http://p.sf.net/sfu/intel-appdev > ___ > enlightenment-svn mailing list > enlightenment-...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib
Docs will come after the code has been flushed out and is "ready". Things may change between now and then (functions/params/etc/etc) so docs will have to wait. dh On 12/26/11 18:32, Vincent Torri wrote: > doc, @since, ChangeLog, NEWS > > how is it possible that someone still forget about that > > Vincent > > On Tue, Dec 27, 2011 at 12:08 AM, Enlightenment SVN > wrote: >> Log: >> Evas: Add functions to get/set if an object is a 'frame object'. >> >> >> >> Author: devilhorns >> Date: 2011-12-26 15:08:17 -0800 (Mon, 26 Dec 2011) >> New Revision: 66535 >> Trac: http://trac.enlightenment.org/e/changeset/66535 >> >> Modified: >> trunk/evas/src/lib/Evas.h >> >> Modified: trunk/evas/src/lib/Evas.h >> === >> --- trunk/evas/src/lib/Evas.h 2011-12-26 23:07:52 UTC (rev 66534) >> +++ trunk/evas/src/lib/Evas.h 2011-12-26 23:08:17 UTC (rev 66535) >> @@ -9050,6 +9050,9 @@ >> * @} >> */ >> >> +EAPI void evas_object_is_frame_object_set(Evas_Object *obj, >> Eina_Bool is_frame); >> +EAPI Eina_Bool evas_object_is_frame_object_get(Evas_Object *obj); >> + >> /** >> * @defgroup Evas_Smart_Group Smart Functions >> * >> -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib
how is it possible that those 2 functions will change in the future ? you return a bool, you set a bool... Vincent On Tue, Dec 27, 2011 at 12:39 AM, Christopher Michael wrote: > Docs will come after the code has been flushed out and is "ready". Things > may change between now and then (functions/params/etc/etc) so docs will have > to wait. > > dh > > > On 12/26/11 18:32, Vincent Torri wrote: >> >> doc, @since, ChangeLog, NEWS >> >> how is it possible that someone still forget about that >> >> Vincent >> >> On Tue, Dec 27, 2011 at 12:08 AM, Enlightenment SVN >> wrote: >>> >>> Log: >>> Evas: Add functions to get/set if an object is a 'frame object'. >>> >>> >>> >>> Author: devilhorns >>> Date: 2011-12-26 15:08:17 -0800 (Mon, 26 Dec 2011) >>> New Revision: 66535 >>> Trac: http://trac.enlightenment.org/e/changeset/66535 >>> >>> Modified: >>> trunk/evas/src/lib/Evas.h >>> >>> Modified: trunk/evas/src/lib/Evas.h >>> === >>> --- trunk/evas/src/lib/Evas.h 2011-12-26 23:07:52 UTC (rev 66534) >>> +++ trunk/evas/src/lib/Evas.h 2011-12-26 23:08:17 UTC (rev 66535) >>> @@ -9050,6 +9050,9 @@ >>> * @} >>> */ >>> >>> +EAPI void evas_object_is_frame_object_set(Evas_Object *obj, >>> Eina_Bool is_frame); >>> +EAPI Eina_Bool evas_object_is_frame_object_get(Evas_Object >>> *obj); >>> + >>> /** >>> * @defgroup Evas_Smart_Group Smart Functions >>> * >>> > > -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib
Function names may change, The functions them selves may prove to be 'not needed', OR may need extra parameters, etc, etc, etc. dh On 12/26/11 18:41, Vincent Torri wrote: > how is it possible that those 2 functions will change in the future ? > you return a bool, you set a bool... > > Vincent > > On Tue, Dec 27, 2011 at 12:39 AM, Christopher Michael > wrote: >> Docs will come after the code has been flushed out and is "ready". Things >> may change between now and then (functions/params/etc/etc) so docs will have >> to wait. >> >> dh >> >> >> On 12/26/11 18:32, Vincent Torri wrote: >>> >>> doc, @since, ChangeLog, NEWS >>> >>> how is it possible that someone still forget about that >>> >>> Vincent >>> >>> On Tue, Dec 27, 2011 at 12:08 AM, Enlightenment SVN >>> wrote: Log: Evas: Add functions to get/set if an object is a 'frame object'. Author: devilhorns Date: 2011-12-26 15:08:17 -0800 (Mon, 26 Dec 2011) New Revision: 66535 Trac: http://trac.enlightenment.org/e/changeset/66535 Modified: trunk/evas/src/lib/Evas.h Modified: trunk/evas/src/lib/Evas.h === --- trunk/evas/src/lib/Evas.h 2011-12-26 23:07:52 UTC (rev 66534) +++ trunk/evas/src/lib/Evas.h 2011-12-26 23:08:17 UTC (rev 66535) @@ -9050,6 +9050,9 @@ * @} */ +EAPI void evas_object_is_frame_object_set(Evas_Object *obj, Eina_Bool is_frame); +EAPI Eina_Bool evas_object_is_frame_object_get(Evas_Object *obj); + /** * @defgroup Evas_Smart_Group Smart Functions * >> >> > -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib
On Mon, Mar 8, 2010 at 5:36 AM, Enlightenment SVN wrote: > Log: > Add macros (actually defines like hint_fill_set) for expand_set to > make it easier for people to know that weight_set handles expansion. > > > Author: devilhorns > Date: 2010-03-08 00:36:08 -0800 (Mon, 08 Mar 2010) > New Revision: 46992 > > Modified: > trunk/evas/src/lib/Evas.h > > Modified: trunk/evas/src/lib/Evas.h > === > --- trunk/evas/src/lib/Evas.h 2010-03-08 08:34:18 UTC (rev 46991) > +++ trunk/evas/src/lib/Evas.h 2010-03-08 08:36:08 UTC (rev 46992) > @@ -497,10 +497,12 @@ > #define EVAS_TEXTURE_RESTRICT_REPEAT 4 /**< tiling clamps and any range > offset repeats */ > #define EVAS_TEXTURE_PAD 5 /**< tiling extends with end > values */ > > -#define EVAS_HINT_EXPAND 1.0 /**< Use with > evas_object_size_hint_weight_set(), evas_object_size_hint_weight_get() */ > +#define EVAS_HINT_EXPAND 1.0 /**< Use with > evas_object_size_hint_weight_set(), evas_object_size_hint_weight_get(), > evas_object_size_hint_expand_set(), evas_object_size_hint_expand_get() */ > #define EVAS_HINT_FILL -1.0 /**< Use with > evas_object_size_hint_align_set(), evas_object_size_hint_align_get(), > evas_object_size_hint_fill_set(), evas_object_size_hint_fill_get() */ > #define evas_object_size_hint_fill_set evas_object_size_hint_align_set /**< > Convenience macro to make it easier to understand that align is also used for > fill properties (as fill is mutually exclusive to align) */ > #define evas_object_size_hint_fill_get evas_object_size_hint_align_get /**< > Convenience macro to make it easier to understand that align is also used for > fill properties (as fill is mutually exclusive to align) */ > +#define evas_object_size_hint_expand_set evas_object_size_hint_weight_set > /**< Convenience macro to make it easier to understand that weight is also > used for expand properties */ > +#define evas_object_size_hint_expand_get evas_object_size_hint_weight_get > /**< Convenience macro to make it easier to understand that weight is also > used for expand properties */ ouch! these macros will make it more error-prone and confusing, not less. Expand would be boolean, but we get double values... meaning? I'd rather add static inline functions that would check and convert parameters. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib
On 03/08/2010 07:50 AM, Gustavo Sverzut Barbieri wrote: > On Mon, Mar 8, 2010 at 5:36 AM, Enlightenment SVN > wrote: >> Log: >> Add macros (actually defines like hint_fill_set) for expand_set to >> make it easier for people to know that weight_set handles expansion. >> > ouch! these macros will make it more error-prone and confusing, not > less. Expand would be boolean, but we get double values... meaning? > > I'd rather add static inline functions that would check and convert > parameters. > > How are they going to make it more error prone ? They are exactly like the fill_set macros ? By your boolean logic there, wouldn't that apply to fill_set also ? dh -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib
On Mon, Mar 8, 2010 at 12:24 PM, Christopher Michael wrote: > On 03/08/2010 07:50 AM, Gustavo Sverzut Barbieri wrote: >> On Mon, Mar 8, 2010 at 5:36 AM, Enlightenment SVN >> wrote: >>> Log: >>> Add macros (actually defines like hint_fill_set) for expand_set to >>> make it easier for people to know that weight_set handles expansion. >>> >> ouch! these macros will make it more error-prone and confusing, not >> less. Expand would be boolean, but we get double values... meaning? >> >> I'd rather add static inline functions that would check and convert >> parameters. >> >> > > How are they going to make it more error prone ? They are exactly like > the fill_set macros ? By your boolean logic there, wouldn't that apply > to fill_set also ? > I'd say yes. If we make one inline and converting as needed, so should we do with the other. > dh > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib
On Mon, Mar 8, 2010 at 12:28 PM, Iván Briano (Sachiel) wrote: > On Mon, Mar 8, 2010 at 12:24 PM, Christopher Michael > wrote: >> On 03/08/2010 07:50 AM, Gustavo Sverzut Barbieri wrote: >>> On Mon, Mar 8, 2010 at 5:36 AM, Enlightenment SVN >>> wrote: Log: Add macros (actually defines like hint_fill_set) for expand_set to make it easier for people to know that weight_set handles expansion. >>> ouch! these macros will make it more error-prone and confusing, not >>> less. Expand would be boolean, but we get double values... meaning? >>> >>> I'd rather add static inline functions that would check and convert >>> parameters. >>> >>> >> >> How are they going to make it more error prone ? They are exactly like >> the fill_set macros ? By your boolean logic there, wouldn't that apply >> to fill_set also ? >> > > I'd say yes. If we make one inline and converting as needed, so > should we do with the other. sure, both of them. fill_set(o, bool, bool), fill_get(o, bool*, bool*) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib
On 03/08/2010 12:05 PM, Gustavo Sverzut Barbieri wrote: > On Mon, Mar 8, 2010 at 12:28 PM, Iván Briano (Sachiel) > wrote: >> On Mon, Mar 8, 2010 at 12:24 PM, Christopher Michael >> wrote: >>> On 03/08/2010 07:50 AM, Gustavo Sverzut Barbieri wrote: On Mon, Mar 8, 2010 at 5:36 AM, Enlightenment SVN wrote: > Log: >Add macros (actually defines like hint_fill_set) for expand_set to >make it easier for people to know that weight_set handles expansion. > ouch! these macros will make it more error-prone and confusing, not less. Expand would be boolean, but we get double values... meaning? I'd rather add static inline functions that would check and convert parameters. >>> >>> How are they going to make it more error prone ? They are exactly like >>> the fill_set macros ? By your boolean logic there, wouldn't that apply >>> to fill_set also ? >>> >> >> I'd say yes. If we make one inline and converting as needed, so >> should we do with the other. > > sure, both of them. fill_set(o, bool, bool), fill_get(o, bool*, bool*) > I still fail to see how my macros make it any more error prone than the existing fill_set macros (that apparently noone complained about until this)...and if anything, it's less confusing for new people imo...fill/expand is much more common (and less confusing) than weight/align in this context. dh -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib
On Mon, Mar 8, 2010 at 2:21 PM, Christopher Michael wrote: > On 03/08/2010 12:05 PM, Gustavo Sverzut Barbieri wrote: >> >> On Mon, Mar 8, 2010 at 12:28 PM, Iván Briano (Sachiel) >> wrote: >>> >>> On Mon, Mar 8, 2010 at 12:24 PM, Christopher Michael >>> wrote: On 03/08/2010 07:50 AM, Gustavo Sverzut Barbieri wrote: > > On Mon, Mar 8, 2010 at 5:36 AM, Enlightenment SVN > wrote: >> >> Log: >> Add macros (actually defines like hint_fill_set) for expand_set to >> make it easier for people to know that weight_set handles expansion. >> > ouch! these macros will make it more error-prone and confusing, not > less. Expand would be boolean, but we get double values... meaning? > > I'd rather add static inline functions that would check and convert > parameters. > > How are they going to make it more error prone ? They are exactly like the fill_set macros ? By your boolean logic there, wouldn't that apply to fill_set also ? >>> >>> I'd say yes. If we make one inline and converting as needed, so >>> should we do with the other. >> >> sure, both of them. fill_set(o, bool, bool), fill_get(o, bool*, bool*) >> > > I still fail to see how my macros make it any more error prone than the > existing fill_set macros (that apparently noone complained about until > this)...and if anything, it's less confusing for new people > imo...fill/expand is much more common (and less confusing) than weight/align > in this context. > The macros don't make it error prone, the point is that both expand and fill are really boolean, just using the weight and align functions, which take a wider range of values, so using fill_set(1, 1) wouldn't fill anything, because it's passing the value straight to align. Having them as functions converting, you just use true/false values and have it pass to weight/align with the right value for each. > dh > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib
On 03/08/2010 12:26 PM, Iván Briano (Sachiel) wrote: > On Mon, Mar 8, 2010 at 2:21 PM, Christopher Michael > wrote: >> On 03/08/2010 12:05 PM, Gustavo Sverzut Barbieri wrote: >>> >>> On Mon, Mar 8, 2010 at 12:28 PM, Iván Briano (Sachiel) >>> wrote: On Mon, Mar 8, 2010 at 12:24 PM, Christopher Michael wrote: > > On 03/08/2010 07:50 AM, Gustavo Sverzut Barbieri wrote: >> >> On Mon, Mar 8, 2010 at 5:36 AM, Enlightenment SVN >> wrote: >>> >>> Log: >>>Add macros (actually defines like hint_fill_set) for expand_set to >>>make it easier for people to know that weight_set handles expansion. >>> >> ouch! these macros will make it more error-prone and confusing, not >> less. Expand would be boolean, but we get double values... meaning? >> >> I'd rather add static inline functions that would check and convert >> parameters. >> >> > > How are they going to make it more error prone ? They are exactly like > the fill_set macros ? By your boolean logic there, wouldn't that apply > to fill_set also ? > I'd say yes. If we make one inline and converting as needed, so should we do with the other. >>> >>> sure, both of them. fill_set(o, bool, bool), fill_get(o, bool*, bool*) >>> >> >> I still fail to see how my macros make it any more error prone than the >> existing fill_set macros (that apparently noone complained about until >> this)...and if anything, it's less confusing for new people >> imo...fill/expand is much more common (and less confusing) than weight/align >> in this context. >> > > The macros don't make it error prone, Ahh ok :) I was under the impression that MY macros somehow made it more error prone.. the point is that both > expand and fill are really boolean, just using the weight and align > functions, Agreed. which take a wider range of values, so using fill_set(1, 1) > wouldn't fill anything, because it's passing the value straight to > align. Having them as functions converting, you just use true/false > values and have it pass to weight/align with the right value for each. > Yea, that makes sense. Thanks for clearing up :) dh >> dh >> > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
Apologies. I misquoted who the patch is from. It is actually from Alex Wu -Original Message- From: Enlightenment SVN [mailto:no-re...@enlightenment.org] Sent: 01 August 2012 15:15 To: enlightenment-...@lists.sourceforge.net Subject: E SVN: devilhorns trunk/evas/src/lib/canvas Log: Evas: Fix trying to clip objects to the framespace clip if the object is going to be deleted. Patch from eduardo.de.barros.l...@intel.com. Author: devilhorns Date: 2012-08-01 07:14:34 -0700 (Wed, 01 Aug 2012) New Revision: 74739 Trac: http://trac.enlightenment.org/e/changeset/74739 Modified: trunk/evas/src/lib/canvas/evas_render.c Modified: trunk/evas/src/lib/canvas/evas_render.c === --- trunk/evas/src/lib/canvas/evas_render.c 2012-08-01 13:32:38 UTC (rev 74738) +++ trunk/evas/src/lib/canvas/evas_render.c 2012-08-01 14:14:34 UTC (rev 74739) @@ -1392,6 +1392,8 @@ } } +if (obj->delete_me) continue; + EINA_RECTANGLE_SET(&clip_rect, e->framespace.clip->cur.geometry.x, e->framespace.clip->cur.geometry.y, -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-svn mailing list enlightenment-...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-svn -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
* Enlightenment SVN [2012-08-01 07:14:35 -0700]: > Log: > Evas: Fix trying to clip objects to the framespace clip if the object > is going to be deleted. Patch from eduardo.de.barros.l...@intel.com. > > > > Author: devilhorns > Date: 2012-08-01 07:14:34 -0700 (Wed, 01 Aug 2012) > New Revision: 74739 > Trac: http://trac.enlightenment.org/e/changeset/74739 > > Modified: > trunk/evas/src/lib/canvas/evas_render.c > > Modified: trunk/evas/src/lib/canvas/evas_render.c > === > --- trunk/evas/src/lib/canvas/evas_render.c 2012-08-01 13:32:38 UTC (rev > 74738) > +++ trunk/evas/src/lib/canvas/evas_render.c 2012-08-01 14:14:34 UTC (rev > 74739) > @@ -1392,6 +1392,8 @@ > } >} > > +if (obj->delete_me) continue; > + Did you bother to build it? > EINA_RECTANGLE_SET(&clip_rect, > e->framespace.clip->cur.geometry.x, > e->framespace.clip->cur.geometry.y, > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > enlightenment-svn mailing list > enlightenment-...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn -- Gustavo Lima Chaves Computer Engineer @ ProFUSION Embedded Systems -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
Hahaha, sorry, I did not. Just caught it now in my build Will fix. -Original Message- From: Gustavo Lima Chaves [mailto:gl...@profusion.mobi] Sent: 01 August 2012 15:27 To: enlightenment-devel@lists.sourceforge.net Cc: enlightenment-...@lists.sourceforge.net Subject: Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas * Enlightenment SVN [2012-08-01 07:14:35 -0700]: > Log: > Evas: Fix trying to clip objects to the framespace clip if the object > is going to be deleted. Patch from eduardo.de.barros.l...@intel.com. > > > > Author: devilhorns > Date: 2012-08-01 07:14:34 -0700 (Wed, 01 Aug 2012) > New Revision: 74739 > Trac: http://trac.enlightenment.org/e/changeset/74739 > > Modified: > trunk/evas/src/lib/canvas/evas_render.c > > Modified: trunk/evas/src/lib/canvas/evas_render.c > === > --- trunk/evas/src/lib/canvas/evas_render.c 2012-08-01 13:32:38 UTC (rev 74738) > +++ trunk/evas/src/lib/canvas/evas_render.c 2012-08-01 14:14:34 UTC (rev 74739) > @@ -1392,6 +1392,8 @@ > } >} > > +if (obj->delete_me) continue; > + Did you bother to build it? > EINA_RECTANGLE_SET(&clip_rect, > e->framespace.clip->cur.geometry.x, > e->framespace.clip->cur.geometry.y, > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > enlightenment-svn mailing list > enlightenment-...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn -- Gustavo Lima Chaves Computer Engineer @ ProFUSION Embedded Systems -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
changelog
Vincent
On Mon, Sep 3, 2012 at 11:41 AM, Enlightenment SVN
wrote:
> Log:
> Evas: When doing a move or geometry_get, we need to make sure that we
> don't try to do these on the framespace clip object. Also, since we
> need the evas to get the framespace clip object, just directly use the
> framespace values from the canvas, rather than function call to get
> those values.
>
>
>
> Author: devilhorns
> Date: 2012-09-03 02:41:01 -0700 (Mon, 03 Sep 2012)
> New Revision: 75989
> Trac: http://trac.enlightenment.org/e/changeset/75989
>
> Modified:
> trunk/evas/src/lib/canvas/evas_object_main.c
>
> Modified: trunk/evas/src/lib/canvas/evas_object_main.c
> ===
> --- trunk/evas/src/lib/canvas/evas_object_main.c2012-09-03 09:39:30
> UTC (rev 75988)
> +++ trunk/evas/src/lib/canvas/evas_object_main.c2012-09-03 09:41:01
> UTC (rev 75989)
> @@ -590,6 +590,7 @@
> EAPI void
> evas_object_move(Evas_Object *obj, Evas_Coord x, Evas_Coord y)
> {
> + Evas *evas;
> int is, was = 0, pass = 0, freeze = 0;
> int nx = 0, ny = 0;
>
> @@ -601,16 +602,14 @@
> nx = x;
> ny = y;
>
> - if (!obj->is_frame)
> + evas = obj->layer->evas;
> +
> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
> {
> if ((!obj->smart.parent) && (obj->smart.smart))
>{
> - int fx, fy;
> -
> - evas_output_framespace_get(obj->layer->evas,
> -&fx, &fy, NULL, NULL);
> - nx += fx;
> - ny += fy;
> + nx += evas->framespace.x;
> + ny += evas->framespace.y;
>}
> }
>
> @@ -749,6 +748,7 @@
> EAPI void
> evas_object_geometry_get(const Evas_Object *obj, Evas_Coord *x, Evas_Coord
> *y, Evas_Coord *w, Evas_Coord *h)
> {
> + Evas *evas;
> int nx = 0, ny = 0;
>
> MAGIC_CHECK(obj, Evas_Object, MAGIC_OBJ);
> @@ -764,16 +764,14 @@
> nx = obj->cur.geometry.x;
> ny = obj->cur.geometry.y;
>
> - if (!obj->is_frame)
> + evas = obj->layer->evas;
> +
> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
> {
> if ((!obj->smart.parent) && (obj->smart.smart))
>{
> - int fx, fy;
> -
> - evas_output_framespace_get(obj->layer->evas,
> -&fx, &fy, NULL, NULL);
> - if (nx > 0) nx -= fx;
> - if (ny > 0) ny -= fy;
> + if (nx > 0) nx -= evas->framespace.x;
> + if (ny > 0) ny -= evas->framespace.y;
>}
> }
>
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
Fixed.
-Original Message-
From: Vincent Torri [mailto:vincent.to...@gmail.com]
Sent: 03 September 2012 11:08
To: enlightenment-devel@lists.sourceforge.net
Subject: Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
changelog
Vincent
On Mon, Sep 3, 2012 at 11:41 AM, Enlightenment SVN
wrote:
> Log:
> Evas: When doing a move or geometry_get, we need to make sure that we
> don't try to do these on the framespace clip object. Also, since we
> need the evas to get the framespace clip object, just directly use the
> framespace values from the canvas, rather than function call to get
> those values.
>
>
>
> Author: devilhorns
> Date: 2012-09-03 02:41:01 -0700 (Mon, 03 Sep 2012)
> New Revision: 75989
> Trac: http://trac.enlightenment.org/e/changeset/75989
>
> Modified:
> trunk/evas/src/lib/canvas/evas_object_main.c
>
> Modified: trunk/evas/src/lib/canvas/evas_object_main.c
> ===
> --- trunk/evas/src/lib/canvas/evas_object_main.c2012-09-03
09:39:30 UTC (rev 75988)
> +++ trunk/evas/src/lib/canvas/evas_object_main.c2012-09-03
09:41:01 UTC (rev 75989)
> @@ -590,6 +590,7 @@
> EAPI void
> evas_object_move(Evas_Object *obj, Evas_Coord x, Evas_Coord y) {
> + Evas *evas;
> int is, was = 0, pass = 0, freeze = 0;
> int nx = 0, ny = 0;
>
> @@ -601,16 +602,14 @@
> nx = x;
> ny = y;
>
> - if (!obj->is_frame)
> + evas = obj->layer->evas;
> +
> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
> {
> if ((!obj->smart.parent) && (obj->smart.smart))
>{
> - int fx, fy;
> -
> - evas_output_framespace_get(obj->layer->evas,
> -&fx, &fy, NULL, NULL);
> - nx += fx;
> - ny += fy;
> + nx += evas->framespace.x;
> + ny += evas->framespace.y;
>}
> }
>
> @@ -749,6 +748,7 @@
> EAPI void
> evas_object_geometry_get(const Evas_Object *obj, Evas_Coord *x,
> Evas_Coord *y, Evas_Coord *w, Evas_Coord *h) {
> + Evas *evas;
> int nx = 0, ny = 0;
>
> MAGIC_CHECK(obj, Evas_Object, MAGIC_OBJ); @@ -764,16 +764,14 @@
> nx = obj->cur.geometry.x;
> ny = obj->cur.geometry.y;
>
> - if (!obj->is_frame)
> + evas = obj->layer->evas;
> +
> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
> {
> if ((!obj->smart.parent) && (obj->smart.smart))
>{
> - int fx, fy;
> -
> - evas_output_framespace_get(obj->layer->evas,
> -&fx, &fy, NULL, NULL);
> - if (nx > 0) nx -= fx;
> - if (ny > 0) ny -= fy;
> + if (nx > 0) nx -= evas->framespace.x;
> + if (ny > 0) ny -= evas->framespace.y;
>}
> }
>
>
>
> --
>
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond.
> Discussions will include endpoint security, mobile security and the
> latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat
landscape has changed and how IT managers can respond. Discussions will
include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
Seriously, all this frame space thing feels out if place.
Realistically speaking, anything but elementary should manage it. The code is
simplified as the only place would have to do with it is elm_win and 99% of the
cases it's automatically fixed by getting "elm_win_resize_object_add" right.
I'm against this frame space since the first version, see my comment comparing
that to EWS. Everyday I see more and more commits like this one that makes my
original complaints being right
--Gustavo
Sent from my iPhone
On 03/09/2012, at 06:41, "Enlightenment SVN" wrote:
> Log:
> Evas: When doing a move or geometry_get, we need to make sure that we
> don't try to do these on the framespace clip object. Also, since we
> need the evas to get the framespace clip object, just directly use the
> framespace values from the canvas, rather than function call to get
> those values.
>
>
>
> Author: devilhorns
> Date: 2012-09-03 02:41:01 -0700 (Mon, 03 Sep 2012)
> New Revision: 75989
> Trac: http://trac.enlightenment.org/e/changeset/75989
>
> Modified:
> trunk/evas/src/lib/canvas/evas_object_main.c
>
> Modified: trunk/evas/src/lib/canvas/evas_object_main.c
> ===
> --- trunk/evas/src/lib/canvas/evas_object_main.c2012-09-03 09:39:30 UTC
> (rev 75988)
> +++ trunk/evas/src/lib/canvas/evas_object_main.c2012-09-03 09:41:01 UTC
> (rev 75989)
> @@ -590,6 +590,7 @@
> EAPI void
> evas_object_move(Evas_Object *obj, Evas_Coord x, Evas_Coord y)
> {
> + Evas *evas;
>int is, was = 0, pass = 0, freeze = 0;
>int nx = 0, ny = 0;
>
> @@ -601,16 +602,14 @@
>nx = x;
>ny = y;
>
> - if (!obj->is_frame)
> + evas = obj->layer->evas;
> +
> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
> {
> if ((!obj->smart.parent) && (obj->smart.smart))
> {
> - int fx, fy;
> -
> - evas_output_framespace_get(obj->layer->evas,
> -&fx, &fy, NULL, NULL);
> - nx += fx;
> - ny += fy;
> + nx += evas->framespace.x;
> + ny += evas->framespace.y;
> }
> }
>
> @@ -749,6 +748,7 @@
> EAPI void
> evas_object_geometry_get(const Evas_Object *obj, Evas_Coord *x, Evas_Coord
> *y, Evas_Coord *w, Evas_Coord *h)
> {
> + Evas *evas;
>int nx = 0, ny = 0;
>
>MAGIC_CHECK(obj, Evas_Object, MAGIC_OBJ);
> @@ -764,16 +764,14 @@
>nx = obj->cur.geometry.x;
>ny = obj->cur.geometry.y;
>
> - if (!obj->is_frame)
> + evas = obj->layer->evas;
> +
> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
> {
> if ((!obj->smart.parent) && (obj->smart.smart))
> {
> - int fx, fy;
> -
> - evas_output_framespace_get(obj->layer->evas,
> -&fx, &fy, NULL, NULL);
> - if (nx > 0) nx -= fx;
> - if (ny > 0) ny -= fy;
> + if (nx > 0) nx -= evas->framespace.x;
> + if (ny > 0) ny -= evas->framespace.y;
> }
> }
>
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
Well if u r fishing for an argument (which i suspect is the case) then u are
out of luck. I refuse to get sucked into this debate. Take it up with the
wayland people who made it so that all client apps in wayland must draw their
own borders.
dh
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Gustavo Sverzut Barbieri wrote:
Seriously, all this frame space thing feels out if place.
Realistically speaking, anything but elementary should manage it. The code is
simplified as the only place would have to do with it is elm_win and 99% of the
cases it's automatically fixed by getting "elm_win_resize_object_add" right.
I'm against this frame space since the first version, see my comment comparing
that to EWS. Everyday I see more and more commits like this one that makes my
original complaints being right
--Gustavo
Sent from my iPhone
On 03/09/2012, at 06:41, "Enlightenment SVN" wrote:
> Log:
> Evas: When doing a move or geometry_get, we need to make sure that we
> don't try to do these on the framespace clip object. Also, since we
> need the evas to get the framespace clip object, just directly use the
> framespace values from the canvas, rather than function call to get
> those values.
>
>
>
> Author: devilhorns
> Date: 2012-09-03 02:41:01 -0700 (Mon, 03 Sep 2012)
> New Revision: 75989
> Trac: http://trac.enlightenment.org/e/changeset/75989
>
> Modified:
> trunk/evas/src/lib/canvas/evas_object_main.c
>
> Modified: trunk/evas/src/lib/canvas/evas_object_main.c
>_
> --- trunk/evas/src/lib/canvas/evas_object_main.c 2012-09-03 09:39:30 UTC (rev
> 75988)
> +++ trunk/evas/src/lib/canvas/evas_object_main.c 2012-09-03 09:41:01 UTC (rev
> 75989)
> @@ -590,6 +590,7 @@
> EAPI void
> evas_object_move(Evas_Object *obj, Evas_Coord x, Evas_Coord y)
> {
> + Evas *evas;
> int is, was = 0, pass = 0, freeze = 0;
> int nx = 0, ny = 0;
>
> @@ -601,16 +602,14 @@
> nx = x;
> ny = y;
>
> - if (!obj->is_frame)
> + evas = obj->layer->evas;
> +
> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
> {
> if ((!obj->smart.parent) && (obj->smart.smart))
> {
> - int fx, fy;
> -
> - evas_output_framespace_get(obj->layer->evas,
> - &fx, &fy, NULL, NULL);
> - nx += fx;
> - ny += fy;
> + nx += evas->framespace.x;
> + ny += evas->framespace.y;
> }
> }
>
> @@ -749,6 +748,7 @@
> EAPI void
> evas_object_geometry_get(const Evas_Object *obj, Evas_Coord *x, Evas_Coord
> *y, Evas_Coord *w, Evas_Coord *h)
> {
> + Evas *evas;
> int nx = 0, ny = 0;
>
> MAGIC_CHECK(obj, Evas_Object, MAGIC_OBJ);
> @@ -764,16 +764,14 @@
> nx = obj->cur.geometry.x;
> ny = obj->cur.geometry.y;
>
> - if (!obj->is_frame)
> + evas = obj->layer->evas;
> +
> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
> {
> if ((!obj->smart.parent) && (obj->smart.smart))
> {
> - int fx, fy;
> -
> - evas_output_framespace_get(obj->layer->evas,
> - &fx, &fy, NULL, NULL);
> - if (nx > 0) nx -= fx;
> - if (ny > 0) ny -= fy;
> + if (nx > 0) nx -= evas->framespace.x;
> + if (ny > 0) ny -= evas->framespace.y;
> }
> }
>
>
>
>_
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>_
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
_
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
Hey devilhorns,
Didn't you agree that the framespace stuff should be outside of Evas,
and just inside Elementary? I remember that last week you talked on
irc about having a patch available for that, so I can only understand
that you and Gustavo are not discussing about the same thing.
And I also agree that all of this should go outside of Evas, handled
only by elm_win.
On Mon, Sep 3, 2012 at 2:21 PM, Christopher Michael
wrote:
> Well if u r fishing for an argument (which i suspect is the case) then u are
> out of luck. I refuse to get sucked into this debate. Take it up with the
> wayland people who made it so that all client apps in wayland must draw their
> own borders.
>
> dh
>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>
> Gustavo Sverzut Barbieri wrote:
>
> Seriously, all this frame space thing feels out if place.
>
> Realistically speaking, anything but elementary should manage it. The code is
> simplified as the only place would have to do with it is elm_win and 99% of
> the cases it's automatically fixed by getting "elm_win_resize_object_add"
> right.
>
> I'm against this frame space since the first version, see my comment
> comparing that to EWS. Everyday I see more and more commits like this one
> that makes my original complaints being right
>
> --Gustavo
>
> Sent from my iPhone
>
> On 03/09/2012, at 06:41, "Enlightenment SVN"
> wrote:
>
>> Log:
>> Evas: When doing a move or geometry_get, we need to make sure that we
>> don't try to do these on the framespace clip object. Also, since we
>> need the evas to get the framespace clip object, just directly use the
>> framespace values from the canvas, rather than function call to get
>> those values.
>>
>>
>>
>> Author: devilhorns
>> Date: 2012-09-03 02:41:01 -0700 (Mon, 03 Sep 2012)
>> New Revision: 75989
>> Trac: http://trac.enlightenment.org/e/changeset/75989
>>
>> Modified:
>> trunk/evas/src/lib/canvas/evas_object_main.c
>>
>> Modified: trunk/evas/src/lib/canvas/evas_object_main.c
>>_
>
>> --- trunk/evas/src/lib/canvas/evas_object_main.c 2012-09-03 09:39:30 UTC
>> (rev 75988)
>> +++ trunk/evas/src/lib/canvas/evas_object_main.c 2012-09-03 09:41:01 UTC
>> (rev 75989)
>> @@ -590,6 +590,7 @@
>> EAPI void
>> evas_object_move(Evas_Object *obj, Evas_Coord x, Evas_Coord y)
>> {
>> + Evas *evas;
>> int is, was = 0, pass = 0, freeze = 0;
>> int nx = 0, ny = 0;
>>
>> @@ -601,16 +602,14 @@
>> nx = x;
>> ny = y;
>>
>> - if (!obj->is_frame)
>> + evas = obj->layer->evas;
>> +
>> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
>> {
>> if ((!obj->smart.parent) && (obj->smart.smart))
>> {
>> - int fx, fy;
>> -
>> - evas_output_framespace_get(obj->layer->evas,
>> - &fx, &fy, NULL, NULL);
>> - nx += fx;
>> - ny += fy;
>> + nx += evas->framespace.x;
>> + ny += evas->framespace.y;
>> }
>> }
>>
>> @@ -749,6 +748,7 @@
>> EAPI void
>> evas_object_geometry_get(const Evas_Object *obj, Evas_Coord *x, Evas_Coord
>> *y, Evas_Coord *w, Evas_Coord *h)
>> {
>> + Evas *evas;
>> int nx = 0, ny = 0;
>>
>> MAGIC_CHECK(obj, Evas_Object, MAGIC_OBJ);
>> @@ -764,16 +764,14 @@
>> nx = obj->cur.geometry.x;
>> ny = obj->cur.geometry.y;
>>
>> - if (!obj->is_frame)
>> + evas = obj->layer->evas;
>> +
>> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
>> {
>> if ((!obj->smart.parent) && (obj->smart.smart))
>> {
>> - int fx, fy;
>> -
>> - evas_output_framespace_get(obj->layer->evas,
>> - &fx, &fy, NULL, NULL);
>> - if (nx > 0) nx -= fx;
>> - if (ny > 0) ny -= fy;
>> + if (nx > 0) nx -= evas->framespace.x;
>> + if (ny > 0) ny -= evas->framespace.y;
>> }
>> }
>>
>>
>>
>>_
>
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>_
>
>> enlightenment-svn mailing list
>> enlightenment-...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
> _
>
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _
>
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat lan
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
Just found them on my backlog, both patches are here:
http://pastebin.com/vJnQbxG4
http://pastebin.com/pdd6aV2Q
Which seems to be exactly that, except that there are still some other
things still being done with framespace inside Evas, for example
inside evas_render.c.
On Mon, Sep 3, 2012 at 4:03 PM, Rafael Antognolli
wrote:
> Hey devilhorns,
>
> Didn't you agree that the framespace stuff should be outside of Evas,
> and just inside Elementary? I remember that last week you talked on
> irc about having a patch available for that, so I can only understand
> that you and Gustavo are not discussing about the same thing.
>
> And I also agree that all of this should go outside of Evas, handled
> only by elm_win.
>
> On Mon, Sep 3, 2012 at 2:21 PM, Christopher Michael
> wrote:
>> Well if u r fishing for an argument (which i suspect is the case) then u are
>> out of luck. I refuse to get sucked into this debate. Take it up with the
>> wayland people who made it so that all client apps in wayland must draw
>> their own borders.
>>
>> dh
>>
>> --
>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>>
>> Gustavo Sverzut Barbieri wrote:
>>
>> Seriously, all this frame space thing feels out if place.
>>
>> Realistically speaking, anything but elementary should manage it. The code
>> is simplified as the only place would have to do with it is elm_win and 99%
>> of the cases it's automatically fixed by getting "elm_win_resize_object_add"
>> right.
>>
>> I'm against this frame space since the first version, see my comment
>> comparing that to EWS. Everyday I see more and more commits like this one
>> that makes my original complaints being right
>>
>> --Gustavo
>>
>> Sent from my iPhone
>>
>> On 03/09/2012, at 06:41, "Enlightenment SVN"
>> wrote:
>>
>>> Log:
>>> Evas: When doing a move or geometry_get, we need to make sure that we
>>> don't try to do these on the framespace clip object. Also, since we
>>> need the evas to get the framespace clip object, just directly use the
>>> framespace values from the canvas, rather than function call to get
>>> those values.
>>>
>>>
>>>
>>> Author: devilhorns
>>> Date: 2012-09-03 02:41:01 -0700 (Mon, 03 Sep 2012)
>>> New Revision: 75989
>>> Trac: http://trac.enlightenment.org/e/changeset/75989
>>>
>>> Modified:
>>> trunk/evas/src/lib/canvas/evas_object_main.c
>>>
>>> Modified: trunk/evas/src/lib/canvas/evas_object_main.c
>>>_
>>
>>> --- trunk/evas/src/lib/canvas/evas_object_main.c 2012-09-03 09:39:30 UTC
>>> (rev 75988)
>>> +++ trunk/evas/src/lib/canvas/evas_object_main.c 2012-09-03 09:41:01 UTC
>>> (rev 75989)
>>> @@ -590,6 +590,7 @@
>>> EAPI void
>>> evas_object_move(Evas_Object *obj, Evas_Coord x, Evas_Coord y)
>>> {
>>> + Evas *evas;
>>> int is, was = 0, pass = 0, freeze = 0;
>>> int nx = 0, ny = 0;
>>>
>>> @@ -601,16 +602,14 @@
>>> nx = x;
>>> ny = y;
>>>
>>> - if (!obj->is_frame)
>>> + evas = obj->layer->evas;
>>> +
>>> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
>>> {
>>> if ((!obj->smart.parent) && (obj->smart.smart))
>>> {
>>> - int fx, fy;
>>> -
>>> - evas_output_framespace_get(obj->layer->evas,
>>> - &fx, &fy, NULL, NULL);
>>> - nx += fx;
>>> - ny += fy;
>>> + nx += evas->framespace.x;
>>> + ny += evas->framespace.y;
>>> }
>>> }
>>>
>>> @@ -749,6 +748,7 @@
>>> EAPI void
>>> evas_object_geometry_get(const Evas_Object *obj, Evas_Coord *x, Evas_Coord
>>> *y, Evas_Coord *w, Evas_Coord *h)
>>> {
>>> + Evas *evas;
>>> int nx = 0, ny = 0;
>>>
>>> MAGIC_CHECK(obj, Evas_Object, MAGIC_OBJ);
>>> @@ -764,16 +764,14 @@
>>> nx = obj->cur.geometry.x;
>>> ny = obj->cur.geometry.y;
>>>
>>> - if (!obj->is_frame)
>>> + evas = obj->layer->evas;
>>> +
>>> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
>>> {
>>> if ((!obj->smart.parent) && (obj->smart.smart))
>>> {
>>> - int fx, fy;
>>> -
>>> - evas_output_framespace_get(obj->layer->evas,
>>> - &fx, &fy, NULL, NULL);
>>> - if (nx > 0) nx -= fx;
>>> - if (ny > 0) ny -= fy;
>>> + if (nx > 0) nx -= evas->framespace.x;
>>> + if (ny > 0) ny -= evas->framespace.y;
>>> }
>>> }
>>>
>>>
>>>
>>>_
>>
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>_
>>
>>> enlightenment-svn mailing list
>>> enlightenment-...@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>>
>> _
>>
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security a
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On 03/09/2012 07:03 PM, Rafael Antognolli wrote:
> Hey devilhorns,
>
> Didn't you agree that the framespace stuff should be outside of Evas,
> and just inside Elementary? I remember that last week you talked on
> irc about having a patch available for that, so I can only understand
> that you and Gustavo are not discussing about the same thing.
Yea, that was my stance originally...or rather, that was my
preference... Except that it cannot be done only inside Elementary. In
an ideal world yes, but what happens if someone creates an application
which does not use Elementary ? Just uses a bare ecore_evas.. then their
objects would not be drawing correctly (read: the could potentially be
drawn below the frame). So, in order to support older applications (or
applications made using Base EFL, not Elm), we have to handle it in Evas.
dh
>
> And I also agree that all of this should go outside of Evas, handled
> only by elm_win.
>
> On Mon, Sep 3, 2012 at 2:21 PM, Christopher Michael
> wrote:
>> Well if u r fishing for an argument (which i suspect is the case) then u are
>> out of luck. I refuse to get sucked into this debate. Take it up with the
>> wayland people who made it so that all client apps in wayland must draw
>> their own borders.
>>
>> dh
>>
>> --
>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>>
>> Gustavo Sverzut Barbieri wrote:
>>
>> Seriously, all this frame space thing feels out if place.
>>
>> Realistically speaking, anything but elementary should manage it. The code
>> is simplified as the only place would have to do with it is elm_win and 99%
>> of the cases it's automatically fixed by getting "elm_win_resize_object_add"
>> right.
>>
>> I'm against this frame space since the first version, see my comment
>> comparing that to EWS. Everyday I see more and more commits like this one
>> that makes my original complaints being right
>>
>> --Gustavo
>>
>> Sent from my iPhone
>>
>> On 03/09/2012, at 06:41, "Enlightenment SVN"
>> wrote:
>>
>>> Log:
>>> Evas: When doing a move or geometry_get, we need to make sure that we
>>> don't try to do these on the framespace clip object. Also, since we
>>> need the evas to get the framespace clip object, just directly use the
>>> framespace values from the canvas, rather than function call to get
>>> those values.
>>>
>>>
>>>
>>> Author: devilhorns
>>> Date: 2012-09-03 02:41:01 -0700 (Mon, 03 Sep 2012)
>>> New Revision: 75989
>>> Trac: http://trac.enlightenment.org/e/changeset/75989
>>>
>>> Modified:
>>> trunk/evas/src/lib/canvas/evas_object_main.c
>>>
>>> Modified: trunk/evas/src/lib/canvas/evas_object_main.c
>>> _
>>
>>> --- trunk/evas/src/lib/canvas/evas_object_main.c 2012-09-03 09:39:30 UTC
>>> (rev 75988)
>>> +++ trunk/evas/src/lib/canvas/evas_object_main.c 2012-09-03 09:41:01 UTC
>>> (rev 75989)
>>> @@ -590,6 +590,7 @@
>>> EAPI void
>>> evas_object_move(Evas_Object *obj, Evas_Coord x, Evas_Coord y)
>>> {
>>> + Evas *evas;
>>> int is, was = 0, pass = 0, freeze = 0;
>>> int nx = 0, ny = 0;
>>>
>>> @@ -601,16 +602,14 @@
>>> nx = x;
>>> ny = y;
>>>
>>> - if (!obj->is_frame)
>>> + evas = obj->layer->evas;
>>> +
>>> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
>>> {
>>> if ((!obj->smart.parent) && (obj->smart.smart))
>>> {
>>> - int fx, fy;
>>> -
>>> - evas_output_framespace_get(obj->layer->evas,
>>> - &fx, &fy, NULL, NULL);
>>> - nx += fx;
>>> - ny += fy;
>>> + nx += evas->framespace.x;
>>> + ny += evas->framespace.y;
>>> }
>>> }
>>>
>>> @@ -749,6 +748,7 @@
>>> EAPI void
>>> evas_object_geometry_get(const Evas_Object *obj, Evas_Coord *x, Evas_Coord
>>> *y, Evas_Coord *w, Evas_Coord *h)
>>> {
>>> + Evas *evas;
>>> int nx = 0, ny = 0;
>>>
>>> MAGIC_CHECK(obj, Evas_Object, MAGIC_OBJ);
>>> @@ -764,16 +764,14 @@
>>> nx = obj->cur.geometry.x;
>>> ny = obj->cur.geometry.y;
>>>
>>> - if (!obj->is_frame)
>>> + evas = obj->layer->evas;
>>> +
>>> + if ((!obj->is_frame) && (obj != evas->framespace.clip))
>>> {
>>> if ((!obj->smart.parent) && (obj->smart.smart))
>>> {
>>> - int fx, fy;
>>> -
>>> - evas_output_framespace_get(obj->layer->evas,
>>> - &fx, &fy, NULL, NULL);
>>> - if (nx > 0) nx -= fx;
>>> - if (ny > 0) ny -= fy;
>>> + if (nx > 0) nx -= evas->framespace.x;
>>> + if (ny > 0) ny -= evas->framespace.y;
>>> }
>>> }
>>>
>>>
>>>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On Mon, 3 Sep 2012 13:42:09 -0300 Gustavo Sverzut Barbieri
said:
> Seriously, all this frame space thing feels out if place.
>
> Realistically speaking, anything but elementary should manage it. The code is
> simplified as the only place would have to do with it is elm_win and 99% of
> the cases it's automatically fixed by getting "elm_win_resize_object_add"
> right.
>
> I'm against this frame space since the first version, see my comment
> comparing that to EWS. Everyday I see more and more commits like this one
> that makes my original complaints being right
if you don't have framespace - wayland BREAKS applications and compatibility.
of course you love to break things as often as possible. it doesn't matter that
regular widget stuff breaks or doesn't break, it's apps that then decide to
place widgets or objects manually that break. imagine you made a space invaders
game. you place objects starting at 0, 0 which is below your titlebar.. but now
they are over/under the titlebar when near the top. this is a break.
> --Gustavo
>
> Sent from my iPhone
>
> On 03/09/2012, at 06:41, "Enlightenment SVN"
> wrote:
>
> > Log:
> > Evas: When doing a move or geometry_get, we need to make sure that we
> > don't try to do these on the framespace clip object. Also, since we
> > need the evas to get the framespace clip object, just directly use the
> > framespace values from the canvas, rather than function call to get
> > those values.
> >
> >
> >
> > Author: devilhorns
> > Date: 2012-09-03 02:41:01 -0700 (Mon, 03 Sep 2012)
> > New Revision: 75989
> > Trac: http://trac.enlightenment.org/e/changeset/75989
> >
> > Modified:
> > trunk/evas/src/lib/canvas/evas_object_main.c
> >
> > Modified: trunk/evas/src/lib/canvas/evas_object_main.c
> > ===
> > --- trunk/evas/src/lib/canvas/evas_object_main.c2012-09-03 09:39:30 UTC
> > (rev 75988) +++ trunk/evas/src/lib/canvas/evas_object_main.c2012-09-03
> > 09:41:01 UTC (rev 75989) @@ -590,6 +590,7 @@
> > EAPI void
> > evas_object_move(Evas_Object *obj, Evas_Coord x, Evas_Coord y)
> > {
> > + Evas *evas;
> >int is, was = 0, pass = 0, freeze = 0;
> >int nx = 0, ny = 0;
> >
> > @@ -601,16 +602,14 @@
> >nx = x;
> >ny = y;
> >
> > - if (!obj->is_frame)
> > + evas = obj->layer->evas;
> > +
> > + if ((!obj->is_frame) && (obj != evas->framespace.clip))
> > {
> > if ((!obj->smart.parent) && (obj->smart.smart))
> > {
> > - int fx, fy;
> > -
> > - evas_output_framespace_get(obj->layer->evas,
> > -&fx, &fy, NULL, NULL);
> > - nx += fx;
> > - ny += fy;
> > + nx += evas->framespace.x;
> > + ny += evas->framespace.y;
> > }
> > }
> >
> > @@ -749,6 +748,7 @@
> > EAPI void
> > evas_object_geometry_get(const Evas_Object *obj, Evas_Coord *x, Evas_Coord
> > *y, Evas_Coord *w, Evas_Coord *h) {
> > + Evas *evas;
> >int nx = 0, ny = 0;
> >
> >MAGIC_CHECK(obj, Evas_Object, MAGIC_OBJ);
> > @@ -764,16 +764,14 @@
> >nx = obj->cur.geometry.x;
> >ny = obj->cur.geometry.y;
> >
> > - if (!obj->is_frame)
> > + evas = obj->layer->evas;
> > +
> > + if ((!obj->is_frame) && (obj != evas->framespace.clip))
> > {
> > if ((!obj->smart.parent) && (obj->smart.smart))
> > {
> > - int fx, fy;
> > -
> > - evas_output_framespace_get(obj->layer->evas,
> > -&fx, &fy, NULL, NULL);
> > - if (nx > 0) nx -= fx;
> > - if (ny > 0) ny -= fy;
> > + if (nx > 0) nx -= evas->framespace.x;
> > + if (ny > 0) ny -= evas->framespace.y;
> > }
> > }
> >
> >
> >
> > --
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > ___
> > enlightenment-svn mailing list
> > enlightenment-...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sou
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On Mon, 03 Sep 2012 20:19:20 + Christopher Michael wrote: > On 03/09/2012 07:03 PM, Rafael Antognolli wrote: > > Hey devilhorns, > > > > Didn't you agree that the framespace stuff should be outside of > > Evas, and just inside Elementary? I remember that last week you > > talked on irc about having a patch available for that, so I can > > only understand that you and Gustavo are not discussing about the > > same thing. > > Yea, that was my stance originally...or rather, that was my > preference... Except that it cannot be done only inside Elementary. > In an ideal world yes, but what happens if someone creates an > application which does not use Elementary ? Just uses a bare > ecore_evas.. then their objects would not be drawing correctly (read: > the could potentially be drawn below the frame). So, in order to > support older applications (or applications made using Base EFL, not > Elm), we have to handle it in Evas. I'm still not sure if I want to use Elementary for things, though I'm giving it a try in an unimportant project. I've not looked much at Wayland yet, but it sounds like a good idea in general. Hope it's implemented well, and not just by us, but by the Wayland people. Also Lua stuff, which I intend to write more backend support for when I get some time, is below the Elementary level, it's edje level stuff. I can see people writing Lua edje proggies that don't use Elementary. I intend to write some real examples like that. -- 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 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On 04/09/12 05:39, David Seikel wrote: > On Mon, 03 Sep 2012 20:19:20 + Christopher Michael > wrote: > >> On 03/09/2012 07:03 PM, Rafael Antognolli wrote: >>> Hey devilhorns, >>> >>> Didn't you agree that the framespace stuff should be outside of >>> Evas, and just inside Elementary? I remember that last week you >>> talked on irc about having a patch available for that, so I can >>> only understand that you and Gustavo are not discussing about the >>> same thing. >> >> Yea, that was my stance originally...or rather, that was my >> preference... Except that it cannot be done only inside Elementary. >> In an ideal world yes, but what happens if someone creates an >> application which does not use Elementary ? Just uses a bare >> ecore_evas.. then their objects would not be drawing correctly (read: >> the could potentially be drawn below the frame). So, in order to >> support older applications (or applications made using Base EFL, not >> Elm), we have to handle it in Evas. > > I'm still not sure if I want to use Elementary for things, though I'm > giving it a try in an unimportant project. I've not looked much at > Wayland yet, but it sounds like a good idea in general. Hope it's > implemented well, and not just by us, but by the Wayland people. > I suppose that is a subjective statement really ;) One persons version of "implemented well" may not match anothers ;) > Also Lua stuff, which I intend to write more backend support for when I > get some time, is below the Elementary level, it's edje level stuff. I > can see people writing Lua edje proggies that don't use Elementary. I > intend to write some real examples like that. > Well, if/when you do, if you find issues in using Lua under Wayland, please report them :) Cheers, dh -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On Tue, 04 Sep 2012 07:19:58 +0100 Christopher Michael wrote: > On 04/09/12 05:39, David Seikel wrote: > > On Mon, 03 Sep 2012 20:19:20 + Christopher Michael > > wrote: > > > >> On 03/09/2012 07:03 PM, Rafael Antognolli wrote: > >>> Hey devilhorns, > >>> > >>> Didn't you agree that the framespace stuff should be outside of > >>> Evas, and just inside Elementary? I remember that last week you > >>> talked on irc about having a patch available for that, so I can > >>> only understand that you and Gustavo are not discussing about the > >>> same thing. > >> > >> Yea, that was my stance originally...or rather, that was my > >> preference... Except that it cannot be done only inside Elementary. > >> In an ideal world yes, but what happens if someone creates an > >> application which does not use Elementary ? Just uses a bare > >> ecore_evas.. then their objects would not be drawing correctly > >> (read: the could potentially be drawn below the frame). So, in > >> order to support older applications (or applications made using > >> Base EFL, not Elm), we have to handle it in Evas. > > > > I'm still not sure if I want to use Elementary for things, though > > I'm giving it a try in an unimportant project. I've not looked > > much at Wayland yet, but it sounds like a good idea in general. > > Hope it's implemented well, and not just by us, but by the Wayland > > people. > > > I suppose that is a subjective statement really ;) One persons > version of "implemented well" may not match anothers ;) > > > Also Lua stuff, which I intend to write more backend support for > > when I get some time, is below the Elementary level, it's edje > > level stuff. I can see people writing Lua edje proggies that don't > > use Elementary. I intend to write some real examples like that. > > > > Well, if/when you do, if you find issues in using Lua under Wayland, > please report them :) I'll know who to spank, er I mean report problems to. B-) Seems that the consensus on the other thread is to stick with keeping the Wayland frame stuff in evas and transparent to apps, so I doubt if it will be a problem for me. -- 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 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On 04/09/12 07:31, David Seikel wrote: > On Tue, 04 Sep 2012 07:19:58 +0100 Christopher Michael > wrote: > >> On 04/09/12 05:39, David Seikel wrote: >>> On Mon, 03 Sep 2012 20:19:20 + Christopher Michael >>> wrote: >>> On 03/09/2012 07:03 PM, Rafael Antognolli wrote: > Hey devilhorns, > > Didn't you agree that the framespace stuff should be outside of > Evas, and just inside Elementary? I remember that last week you > talked on irc about having a patch available for that, so I can > only understand that you and Gustavo are not discussing about the > same thing. Yea, that was my stance originally...or rather, that was my preference... Except that it cannot be done only inside Elementary. In an ideal world yes, but what happens if someone creates an application which does not use Elementary ? Just uses a bare ecore_evas.. then their objects would not be drawing correctly (read: the could potentially be drawn below the frame). So, in order to support older applications (or applications made using Base EFL, not Elm), we have to handle it in Evas. >>> >>> I'm still not sure if I want to use Elementary for things, though >>> I'm giving it a try in an unimportant project. I've not looked >>> much at Wayland yet, but it sounds like a good idea in general. >>> Hope it's implemented well, and not just by us, but by the Wayland >>> people. >>> >> I suppose that is a subjective statement really ;) One persons >> version of "implemented well" may not match anothers ;) >> >>> Also Lua stuff, which I intend to write more backend support for >>> when I get some time, is below the Elementary level, it's edje >>> level stuff. I can see people writing Lua edje proggies that don't >>> use Elementary. I intend to write some real examples like that. >>> >> >> Well, if/when you do, if you find issues in using Lua under Wayland, >> please report them :) > > I'll know who to spank, er I mean report problems to. B-) > Hahahaha :) You can see that bullseye painted on my back from there huh ? :) > Seems that the consensus on the other thread is to stick with keeping > the Wayland frame stuff in evas and transparent to apps, so I doubt if > it will be a problem for me. > It's really the only way to sanely do it. Well, that was the goal...to be as transparent as possible and not have to require a bunch of changes on the application side. When all is said and done, you should not have any problems (assuming you are doing nothing engine specific in your app). dh -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On Tue, 04 Sep 2012 07:40:30 +0100 Christopher Michael wrote: > On 04/09/12 07:31, David Seikel wrote: > > On Tue, 04 Sep 2012 07:19:58 +0100 Christopher Michael > > wrote: > > > >> On 04/09/12 05:39, David Seikel wrote: > >>> On Mon, 03 Sep 2012 20:19:20 + Christopher Michael > >>> wrote: > >>> > On 03/09/2012 07:03 PM, Rafael Antognolli wrote: > > Hey devilhorns, > > > > Didn't you agree that the framespace stuff should be outside of > > Evas, and just inside Elementary? I remember that last week you > > talked on irc about having a patch available for that, so I can > > only understand that you and Gustavo are not discussing about > > the same thing. > > Yea, that was my stance originally...or rather, that was my > preference... Except that it cannot be done only inside > Elementary. In an ideal world yes, but what happens if someone > creates an application which does not use Elementary ? Just uses > a bare ecore_evas.. then their objects would not be drawing > correctly (read: the could potentially be drawn below the > frame). So, in order to support older applications (or > applications made using Base EFL, not Elm), we have to handle it > in Evas. > >>> > >>> I'm still not sure if I want to use Elementary for things, though > >>> I'm giving it a try in an unimportant project. I've not looked > >>> much at Wayland yet, but it sounds like a good idea in general. > >>> Hope it's implemented well, and not just by us, but by the Wayland > >>> people. > >>> > >> I suppose that is a subjective statement really ;) One persons > >> version of "implemented well" may not match anothers ;) > >> > >>> Also Lua stuff, which I intend to write more backend support for > >>> when I get some time, is below the Elementary level, it's edje > >>> level stuff. I can see people writing Lua edje proggies that > >>> don't use Elementary. I intend to write some real examples like > >>> that. > >>> > >> > >> Well, if/when you do, if you find issues in using Lua under > >> Wayland, please report them :) > > > > I'll know who to spank, er I mean report problems to. B-) > > > > Hahahaha :) You can see that bullseye painted on my back from there > huh ? :) /me hides the can of paint and the still dripping paint brush. Er, um, what bullseye painted on your back? > > Seems that the consensus on the other thread is to stick with > > keeping the Wayland frame stuff in evas and transparent to apps, so > > I doubt if it will be a problem for me. > > > It's really the only way to sanely do it. Well, that was the > goal...to be as transparent as possible and not have to require a > bunch of changes on the application side. When all is said and done, > you should not have any problems (assuming you are doing nothing > engine specific in your app). Yep, that's what I want to see, cross platform transparency. Saves me from having to worry about it. B-) -- 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 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On 04/09/12 07:48, David Seikel wrote: > On Tue, 04 Sep 2012 07:40:30 +0100 Christopher Michael > wrote: > >> On 04/09/12 07:31, David Seikel wrote: >>> On Tue, 04 Sep 2012 07:19:58 +0100 Christopher Michael >>> wrote: >>> On 04/09/12 05:39, David Seikel wrote: > On Mon, 03 Sep 2012 20:19:20 + Christopher Michael > wrote: > >> On 03/09/2012 07:03 PM, Rafael Antognolli wrote: >>> Hey devilhorns, >>> >>> Didn't you agree that the framespace stuff should be outside of >>> Evas, and just inside Elementary? I remember that last week you >>> talked on irc about having a patch available for that, so I can >>> only understand that you and Gustavo are not discussing about >>> the same thing. >> >> Yea, that was my stance originally...or rather, that was my >> preference... Except that it cannot be done only inside >> Elementary. In an ideal world yes, but what happens if someone >> creates an application which does not use Elementary ? Just uses >> a bare ecore_evas.. then their objects would not be drawing >> correctly (read: the could potentially be drawn below the >> frame). So, in order to support older applications (or >> applications made using Base EFL, not Elm), we have to handle it >> in Evas. > > I'm still not sure if I want to use Elementary for things, though > I'm giving it a try in an unimportant project. I've not looked > much at Wayland yet, but it sounds like a good idea in general. > Hope it's implemented well, and not just by us, but by the Wayland > people. > I suppose that is a subjective statement really ;) One persons version of "implemented well" may not match anothers ;) > Also Lua stuff, which I intend to write more backend support for > when I get some time, is below the Elementary level, it's edje > level stuff. I can see people writing Lua edje proggies that > don't use Elementary. I intend to write some real examples like > that. > Well, if/when you do, if you find issues in using Lua under Wayland, please report them :) >>> >>> I'll know who to spank, er I mean report problems to. B-) >>> >> >> Hahahaha :) You can see that bullseye painted on my back from there >> huh ? :) > > /me hides the can of paint and the still dripping paint brush. > > Er, um, what bullseye painted on your back? > LMAO :) >>> Seems that the consensus on the other thread is to stick with >>> keeping the Wayland frame stuff in evas and transparent to apps, so >>> I doubt if it will be a problem for me. >>> >> It's really the only way to sanely do it. Well, that was the >> goal...to be as transparent as possible and not have to require a >> bunch of changes on the application side. When all is said and done, >> you should not have any problems (assuming you are doing nothing >> engine specific in your app). > > Yep, that's what I want to see, cross platform transparency. Saves me > from having to worry about it. B-) > Indeed :) That's the idea ;) App developers won't have to worry about if their app will function in Wayland (assuming they have coded generically). dh -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On 05/25/2012 02:55 PM, Enlightenment SVN wrote: > Log: > Evas: Fix clipping issue for wayland engines (were drawing outside the >viewort). This fixes the Elm Map 3D test issue where the cube was >drawing onto the window border (and perhaps other tests). > > > > Author: devilhorns > Date: 2012-05-25 05:55:45 -0700 (Fri, 25 May 2012) > New Revision: 71426 > Trac: http://trac.enlightenment.org/e/changeset/71426 > > Modified: >trunk/evas/src/lib/canvas/evas_render.c > > + if ((!strcmp(e->engine.module->definition->name, "wayland_shm")) || > + (!strcmp(e->engine.module->definition->name, "wayland_egl"))) strncmp(e->...->name, "wayland", 7)? S. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On Tue, Jul 3, 2012 at 4:30 AM, Enlightenment SVN wrote: > Log: > Evas: Merge evas_object_image changes from Tizen to upstream EFL. > > > > Author: devilhorns dh, this patch touches highly sensible parts of evas. Next time you integrate a commit as such, please split the cosmetic/whitespace/reindent/rewrap into different patches than the actual changes. It was super annoying to review this, and maybe something passed unnoticed because of this mess. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On Tue, Jul 3, 2012 at 4:30 AM, Enlightenment SVN wrote: > Log: > Evas: Merge evas_object_image changes from Tizen to upstream EFL. > > > > Author: devilhorns >dh, this patch touches highly sensible parts of evas. Next time you >integrate a commit as such, please split the >cosmetic/whitespace/reindent/rewrap into different patches than the >actual changes. >It was super annoying to review this, and maybe something passed >unnoticed because of this mess. Are you looking at a different commit here or something ? Because I just looked at this commit again, and I find nothing in there that is hard to read or annoying. If this commit annoyed you, I'm sorry. Perhaps I should just run every commit through you first to make sure you are not going to get annoyed by it ? I get annoyed by commits all the time, but you don't see me making mountains out of molehills. Anyone else feeling the need to jump on the bandwagon here ? If so, speak now. Getting a bit tired of all this nonsense so if you want to say something, now is the time so we can all get off our high horses and move forward. dh -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbieri@... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On Tue, Jul 3, 2012 at 2:26 PM, wrote:
> On Tue, Jul 3, 2012 at 4:30 AM, Enlightenment SVN
> wrote:
>> Log:
>> Evas: Merge evas_object_image changes from Tizen to upstream EFL.
>>
>>
>>
>> Author: devilhorns
>
>>dh, this patch touches highly sensible parts of evas. Next time you
>>integrate a commit as such, please split the
>>cosmetic/whitespace/reindent/rewrap into different patches than the
>>actual changes.
>
>>It was super annoying to review this, and maybe something passed
>>unnoticed because of this mess.
> Are you looking at a different commit here or something ? Because I just
> looked at this commit again, and I find nothing in there that is hard to read
> or annoying.
> If this commit annoyed you, I'm sorry. Perhaps I should just run every commit
> through you first to make sure you are not going to get annoyed by it ? I get
> annoyed by commits all the time, but you don't see me making mountains out of
> molehills.
> Anyone else feeling the need to jump on the bandwagon here ? If so, speak
> now. Getting a bit tired of all this nonsense so if you want to say
> something, now is the time so we can all get off our high horses and move
> forward.
Looking at the first part of the commit:
- o->engine_data =
obj->layer->evas->engine.func->image_data_get(obj->layer->evas->engine.data.output,
-
o->engine_data,
- 0,
- &data,
-
&o->load_error);
- return evas_object_image_data_convert_internal(o, data, to_cspace);
+ o->engine_data =
+
obj->layer->evas->engine.func->image_data_get(obj->layer->evas->engine.data.output,
+ o->engine_data, 0, &data,
+ &o->load_error);
this is pure cosmetic. But who knows? Needs to investigate because right after:
+ result = evas_object_image_data_convert_internal(o, data, to_cspace);
+ if (o->engine_data)
+ {
+o->engine_data =
+
obj->layer->evas->engine.func->image_data_put(obj->layer->evas->engine.data.output,
+o->engine_data, data);
+ }
which may impact something.
If it was clear that the first one was just cosmetic and split into
another patch, we could ignore it and just look at the relevant
changes.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
From: "Gustavo Sverzut Barbieri"
To: "Enlightenment developer list"
Sent: Tuesday, July 3, 2012 7:13:02 PM
Subject: Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On Tue, Jul 3, 2012 at 2:26 PM, wrote:
> On Tue, Jul 3, 2012 at 4:30 AM, Enlightenment SVN
> wrote:
>> Log:
>> Evas: Merge evas_object_image changes from Tizen to upstream EFL.
>>
>>
>>
>> Author: devilhorns
>
>>dh, this patch touches highly sensible parts of evas. Next time you
>>integrate a commit as such, please split the
>>cosmetic/whitespace/reindent/rewrap into different patches than the
>>actual changes.
>
>>It was super annoying to review this, and maybe something passed
>>unnoticed because of this mess.
> Are you looking at a different commit here or something ? Because I just
> looked at this commit again, and I find nothing in there that is hard to read
> or annoying.
> If this commit annoyed you, I'm sorry. Perhaps I should just run every commit
> through you first to make sure you are not going to get annoyed by it ? I get
> annoyed by commits all the time, but you don't see me making mountains out of
> molehills.
> Anyone else feeling the need to jump on the bandwagon here ? If so, speak
> now. Getting a bit tired of all this nonsense so if you want to say
> something, now is the time so we can all get off our high horses and move
> forward.
Looking at the first part of the commit:
- o->engine_data =
obj->layer->evas->engine.func->image_data_get(obj->layer->evas->engine.data.output,
-
o->engine_data,
- 0,
- &data,
-
&o->load_error);
- return evas_object_image_data_convert_internal(o, data, to_cspace);
+ o->engine_data =
+
obj->layer->evas->engine.func->image_data_get(obj->layer->evas->engine.data.output,
+ o->engine_data, 0, &data,
+ &o->load_error);
this is pure cosmetic. But who knows? Needs to investigate because right after:
+ result = evas_object_image_data_convert_internal(o, data, to_cspace);
+ if (o->engine_data)
+ {
+ o->engine_data =
+
obj->layer->evas->engine.func->image_data_put(obj->layer->evas->engine.data.output,
+ o->engine_data, data);
+ }
which may impact something.
If it was clear that the first one was just cosmetic and split into
another patch, we could ignore it and just look at the relevant
changes.
And the relevant changes can still be viewed in the same patch above ... I am
not seeing the problem here. If you read the patch and see that something is a
cosmetic change, then just read over it and go "ok, that's a cosmetic change, I
can ignore that" and move on.
dh
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
On Sun, 9 Aug 2009, Enlightenment SVN wrote:
> Log:
> Formatting
>
> Author: devilhorns
> Date: 2009-08-09 09:41:51 -0700 (Sun, 09 Aug 2009)
> New Revision: 41648
>
> Modified:
> trunk/evas/src/lib/canvas/evas_render.c
>
> Modified: trunk/evas/src/lib/canvas/evas_render.c
> ===
> --- trunk/evas/src/lib/canvas/evas_render.c 2009-08-09 15:47:44 UTC (rev
> 41647)
> +++ trunk/evas/src/lib/canvas/evas_render.c 2009-08-09 16:41:51 UTC (rev
> 41648)
> @@ -298,7 +298,8 @@
> }
> }
>
> -Eina_Bool pending_change(void *data, __UNUSED__ void *gdata)
> +Eina_Bool
> +pending_change(void *data, __UNUSED__ void *gdata)
> {
>Evas_Object *obj;
and put __UNUSED__ after the variable :-)
Vincent
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
Vincent,
Not entirely sure what you are saying here. All I did was fix the
formatting.
dh
Vincent Torri wrote:
>
> On Sun, 9 Aug 2009, Enlightenment SVN wrote:
>
>> Log:
>> Formatting
>>
>> Author: devilhorns
>> Date: 2009-08-09 09:41:51 -0700 (Sun, 09 Aug 2009)
>> New Revision: 41648
>>
>> Modified:
>> trunk/evas/src/lib/canvas/evas_render.c
>>
>> Modified: trunk/evas/src/lib/canvas/evas_render.c
>> ===
>> --- trunk/evas/src/lib/canvas/evas_render.c 2009-08-09 15:47:44 UTC (rev
>> 41647)
>> +++ trunk/evas/src/lib/canvas/evas_render.c 2009-08-09 16:41:51 UTC (rev
>> 41648)
>> @@ -298,7 +298,8 @@
>> }
>> }
>>
>> -Eina_Bool pending_change(void *data, __UNUSED__ void *gdata)
>> +Eina_Bool
>> +pending_change(void *data, __UNUSED__ void *gdata)
>> {
>>Evas_Object *obj;
>
> and put __UNUSED__ after the variable :-)
>
> Vincent
>
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
> Not entirely sure what you are saying here. All I did was fix the formatting. >>> -pending_change(void *data, __UNUSED__ void *gdata) >>> +pending_change(void *data, void *gdata __UNUSED__) Vincent -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/lib/canvas
Thought that's what you meant...just wanted to be sure. Thanks :) dh Vincent Torri wrote: > >> Not entirely sure what you are saying here. All I did was fix the >> formatting. > -pending_change(void *data, __UNUSED__ void *gdata) > +pending_change(void *data, void *gdata __UNUSED__) > > Vincent > -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/modules/engines/software_x11
On Thu, 21 Apr 2011 08:21:40 -0700 "Enlightenment SVN"
said:
oops - sorry'bout that. copy & paste typo fun++
> Log:
> Evas: Fix typos from 'old mans' recent commit sot hings build again
> wrt xcb.
>
>
>
> Author: devilhorns
> Date: 2011-04-21 08:21:40 -0700 (Thu, 21 Apr 2011)
> New Revision: 58804
> Trac: http://trac.enlightenment.org/e/changeset/58804
>
> Modified:
> trunk/evas/src/modules/engines/software_x11/evas_xcb_outbuf.c
>
> Modified: trunk/evas/src/modules/engines/software_x11/evas_xcb_outbuf.c
> ===
> --- trunk/evas/src/modules/engines/software_x11/evas_xcb_outbuf.c
> 2011-04-21 15:02:34 UTC (rev 58803) +++
> trunk/evas/src/modules/engines/software_x11/evas_xcb_outbuf.c
> 2011-04-21 15:21:40 UTC (rev 58804) @@ -571,7 +571,7 @@ alpha,
> EVAS_COLORSPACE_ARGB); if (!im)
>{
> - _unfind_xob(obr->xob, 0);
> + _unfind_xcbob(obr->xcbob, 0);
> free(obr);
> return NULL;
>}
>
>
> --
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/modules/engines/software_x11
On 04/21/2011 07:33 PM, Carsten Haitzler (The Rasterman) wrote: > On Thu, 21 Apr 2011 08:21:40 -0700 "Enlightenment SVN" > said: > > oops - sorry'bout that. copy& paste typo fun++ > No worries :) dh >> Log: >> Evas: Fix typos from 'old mans' recent commit sot hings build again >>wrt xcb. >> >> >> >> Author: devilhorns >> Date: 2011-04-21 08:21:40 -0700 (Thu, 21 Apr 2011) >> New Revision: 58804 >> Trac: http://trac.enlightenment.org/e/changeset/58804 >> >> Modified: >>trunk/evas/src/modules/engines/software_x11/evas_xcb_outbuf.c >> >> Modified: trunk/evas/src/modules/engines/software_x11/evas_xcb_outbuf.c >> === > -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/modules/engines/gl_x11
On Thu, 9 Jun 2011, Enlightenment SVN wrote:
> Log:
> Evas: GL_X11 engine: Do not set UNUSED on variables that we actually
> use and remove some extra whitespace between functions.
just a note : the use of the attribute means that the variable can be
unused. It's not a requirement. See:
http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Variable-Attributes.html
Vincent
>
>
>
> Author: devilhorns
> Date: 2011-06-09 12:25:21 -0700 (Thu, 09 Jun 2011)
> New Revision: 60153
> Trac: http://trac.enlightenment.org/e/changeset/60153
>
> Modified:
> trunk/evas/src/modules/engines/gl_x11/evas_engine.c
>
> Modified: trunk/evas/src/modules/engines/gl_x11/evas_engine.c
> ===
> --- trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2011-06-09
> 19:03:39 UTC (rev 60152)
> +++ trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2011-06-09
> 19:25:21 UTC (rev 60153)
> @@ -1931,7 +1931,7 @@
> }
>
> static void
> -eng_image_map_draw(void *data __UNUSED__, void *context, void *surface, void
> *image, int npoints, RGBA_Map_Point *p, int smooth, int level)
> +eng_image_map_draw(void *data, void *context, void *surface, void *image,
> int npoints, RGBA_Map_Point *p, int smooth, int level)
> {
>Evas_GL_Image *gim = image;
>Render_Engine *re;
> @@ -1982,7 +1982,7 @@
> }
>
> static void *
> -eng_image_map_surface_new(void *data __UNUSED__, int w, int h, int alpha)
> +eng_image_map_surface_new(void *data, int w, int h, int alpha)
> {
>Render_Engine *re;
>
> @@ -2011,7 +2011,7 @@
> }
>
> static void
> -eng_image_cache_flush(void *data __UNUSED__)
> +eng_image_cache_flush(void *data)
> {
>Render_Engine *re;
>int tmp_size;
> @@ -2026,7 +2026,7 @@
> }
>
> static void
> -eng_image_cache_set(void *data __UNUSED__, int bytes)
> +eng_image_cache_set(void *data, int bytes)
> {
>Render_Engine *re;
>
> @@ -2039,17 +2039,14 @@
> static int
> eng_image_cache_get(void *data __UNUSED__)
> {
> - Render_Engine *re;
> -
> - re = (Render_Engine *)data;
>return evas_common_image_get_cache();
> }
>
> -
> static void
> eng_image_stride_get(void *data __UNUSED__, void *image, int *stride)
> {
>Evas_GL_Image *im = image;
> +
>*stride = im->w * 4;
>if ((im->tex) && (im->tex->pt->dyn.img))
> {
> @@ -2325,7 +2322,6 @@
>return sfc;
> }
>
> -
> static int
> eng_gl_surface_destroy(void *data, void *surface)
> {
> @@ -2379,8 +2375,6 @@
>return 1;
> }
>
> -
> -
> static void *
> eng_gl_context_create(void *data, void *share_context)
> {
> @@ -2457,7 +2451,6 @@
>return ctx;
> }
>
> -
> static int
> eng_gl_context_destroy(void *data, void *context)
> {
> @@ -2513,8 +2506,6 @@
>return 1;
> }
>
> -
> -
> static int
> eng_gl_make_current(void *data, void *surface, void *context)
> {
>
>
> --
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
>
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/modules/engines/gl_x11
On 06/09/2011 03:30 PM, Vincent Torri wrote:
>
>
> On Thu, 9 Jun 2011, Enlightenment SVN wrote:
>
>> Log:
>> Evas: GL_X11 engine: Do not set UNUSED on variables that we actually
>> use and remove some extra whitespace between functions.
>
> just a note : the use of the attribute means that the variable can be
> unused. It's not a requirement. See:
>
> http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Variable-Attributes.html
>
> Vincent
>
"This attribute, attached to a variable, means that the variable is
meant to be possibly unused."
In all these cases that I fixed, the variable WAS indeed usednot
'possibly unused' at all ;)
But thanks for the note !! :)
dh
>>
>>
>>
>> Author: devilhorns
>> Date: 2011-06-09 12:25:21 -0700 (Thu, 09 Jun 2011)
>> New Revision: 60153
>> Trac: http://trac.enlightenment.org/e/changeset/60153
>>
>> Modified:
>> trunk/evas/src/modules/engines/gl_x11/evas_engine.c
>>
>> Modified: trunk/evas/src/modules/engines/gl_x11/evas_engine.c
>> ===
>> --- trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2011-06-09
>> 19:03:39 UTC (rev 60152)
>> +++ trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2011-06-09
>> 19:25:21 UTC (rev 60153)
>> @@ -1931,7 +1931,7 @@
>> }
>>
>> static void
>> -eng_image_map_draw(void *data __UNUSED__, void *context, void *surface,
>> void *image, int npoints, RGBA_Map_Point *p, int smooth, int level)
>> +eng_image_map_draw(void *data, void *context, void *surface, void *image,
>> int npoints, RGBA_Map_Point *p, int smooth, int level)
>> {
>> Evas_GL_Image *gim = image;
>> Render_Engine *re;
>> @@ -1982,7 +1982,7 @@
>> }
>>
>> static void *
>> -eng_image_map_surface_new(void *data __UNUSED__, int w, int h, int alpha)
>> +eng_image_map_surface_new(void *data, int w, int h, int alpha)
>> {
>> Render_Engine *re;
>>
>> @@ -2011,7 +2011,7 @@
>> }
>>
>> static void
>> -eng_image_cache_flush(void *data __UNUSED__)
>> +eng_image_cache_flush(void *data)
>> {
>> Render_Engine *re;
>> int tmp_size;
>> @@ -2026,7 +2026,7 @@
>> }
>>
>> static void
>> -eng_image_cache_set(void *data __UNUSED__, int bytes)
>> +eng_image_cache_set(void *data, int bytes)
>> {
>> Render_Engine *re;
>>
>> @@ -2039,17 +2039,14 @@
>> static int
>> eng_image_cache_get(void *data __UNUSED__)
>> {
>> - Render_Engine *re;
>> -
>> - re = (Render_Engine *)data;
>> return evas_common_image_get_cache();
>> }
>>
>> -
>> static void
>> eng_image_stride_get(void *data __UNUSED__, void *image, int *stride)
>> {
>> Evas_GL_Image *im = image;
>> +
>> *stride = im->w * 4;
>> if ((im->tex)&& (im->tex->pt->dyn.img))
>> {
>> @@ -2325,7 +2322,6 @@
>> return sfc;
>> }
>>
>> -
>> static int
>> eng_gl_surface_destroy(void *data, void *surface)
>> {
>> @@ -2379,8 +2375,6 @@
>> return 1;
>> }
>>
>> -
>> -
>> static void *
>> eng_gl_context_create(void *data, void *share_context)
>> {
>> @@ -2457,7 +2451,6 @@
>> return ctx;
>> }
>>
>> -
>> static int
>> eng_gl_context_destroy(void *data, void *context)
>> {
>> @@ -2513,8 +2506,6 @@
>> return 1;
>> }
>>
>> -
>> -
>> static int
>> eng_gl_make_current(void *data, void *surface, void *context)
>> {
>>
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/modules/engines/gl_x11
I'm sorry. It was my mistake. I should have searched where it uded. 2012. 5. 16. 오후 5:03에 "Enlightenment SVN" 님이 작성: > Log: > Evas (gl_x11): Unbreak build for gles_sgx & s3c6410. Someone removed a > variable that was actually being used :( > > > > Author: devilhorns > Date: 2012-05-16 01:03:31 -0700 (Wed, 16 May 2012) > New Revision: 71146 > Trac: http://trac.enlightenment.org/e/changeset/71146 > > Modified: > trunk/evas/src/modules/engines/gl_x11/evas_engine.c > > Modified: trunk/evas/src/modules/engines/gl_x11/evas_engine.c > === > --- trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2012-05-16 > 07:44:43 UTC (rev 71145) > +++ trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2012-05-16 > 08:03:31 UTC (rev 71146) > @@ -2988,6 +2988,8 @@ >w = h = 2; > > #if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX) > + int max_samples = 0; > + >glGetIntegerv(GL_MAX_SAMPLES_IMG, &max_samples); > >// Check if msaa_support is supported > @@ -3011,9 +3013,9 @@ > } > > #endif > + >glGetIntegerv(GL_MAX_RENDERBUFFER_SIZE, &re->gl_cap.max_rb_size); > > - > #if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX) >count = (re->gl_cap.msaa_support) ? 4 : 1; > > @@ -3032,7 +3034,7 @@ > re->gl_cap.stencil_8[i] = _check_gl_surface_format(0, 0, > GL_STENCIL_ATTACHMENT, GL_STENCIL_INDEX8, re->gl_cap.msaa_samples[i]); > } > > - #else > +#else >count = (re->gl_cap.msaa_support) ? 4 : 1; > >for (i = 0; i < count; i++) > > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > enlightenment-svn mailing list > enlightenment-...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/modules/engines/gl_x11
No worries :) All fixed now :) dh > -Original Message- > From: Jihoon Kim [mailto:imfin...@gmail.com] > Sent: 16 May 2012 14:00 > To: enlightenment-devel@lists.sourceforge.net > Subject: Re: [E-devel] E SVN: devilhorns > trunk/evas/src/modules/engines/gl_x11 > > I'm sorry. It was my mistake. I should have searched where it uded. > 2012. 5. 16. 오후 5:03에 "Enlightenment SVN" re...@enlightenment.org>님이 작성: > > > Log: > > Evas (gl_x11): Unbreak build for gles_sgx & s3c6410. Someone removed > a > > variable that was actually being used :( > > > > > > > > Author: devilhorns > > Date: 2012-05-16 01:03:31 -0700 (Wed, 16 May 2012) > > New Revision: 71146 > > Trac: http://trac.enlightenment.org/e/changeset/71146 > > > > Modified: > > trunk/evas/src/modules/engines/gl_x11/evas_engine.c > > > > Modified: trunk/evas/src/modules/engines/gl_x11/evas_engine.c > > === > > --- trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2012-05-16 > > 07:44:43 UTC (rev 71145) > > +++ trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2012-05-16 > > 08:03:31 UTC (rev 71146) > > @@ -2988,6 +2988,8 @@ > >w = h = 2; > > > > #if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX) > > + int max_samples = 0; > > + > >glGetIntegerv(GL_MAX_SAMPLES_IMG, &max_samples); > > > >// Check if msaa_support is supported > > @@ -3011,9 +3013,9 @@ > > } > > > > #endif > > + > >glGetIntegerv(GL_MAX_RENDERBUFFER_SIZE, &re->gl_cap.max_rb_size); > > > > - > > #if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX) > >count = (re->gl_cap.msaa_support) ? 4 : 1; > > > > @@ -3032,7 +3034,7 @@ > > re->gl_cap.stencil_8[i] = _check_gl_surface_format(0, 0, > > GL_STENCIL_ATTACHMENT, GL_STENCIL_INDEX8, re- > >gl_cap.msaa_samples[i]); > > } > > > > - #else > > +#else > >count = (re->gl_cap.msaa_support) ? 4 : 1; > > > >for (i = 0; i < count; i++) > > > > > > > > - > - > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. > Discussions > > will include endpoint security, mobile security and the latest in > malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > ___ > > enlightenment-svn mailing list > > enlightenment-...@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn > > > --- > --- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions > will include endpoint security, mobile security and the latest in > malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/modules/engines/gl_x11
this one and the previous one should be backported
Vincent
On Wed, Dec 14, 2011 at 7:52 PM, Enlightenment SVN
wrote:
> Log:
> Evas: Gl_X11: Fix typo? for __UNUSED__ param.
>
>
>
> Author: devilhorns
> Date: 2011-12-14 10:52:42 -0800 (Wed, 14 Dec 2011)
> New Revision: 66224
> Trac: http://trac.enlightenment.org/e/changeset/66224
>
> Modified:
> trunk/evas/src/modules/engines/gl_x11/evas_engine.c
>
> Modified: trunk/evas/src/modules/engines/gl_x11/evas_engine.c
> ===
> --- trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2011-12-14 18:44:20
> UTC (rev 66223)
> +++ trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2011-12-14 18:52:42
> UTC (rev 66224)
> @@ -3703,7 +3703,7 @@
> }
>
> static Eina_Bool
> -eng_image_can_region_get(void *data__UNUSED__, void *image)
> +eng_image_can_region_get(void *data __UNUSED__, void *image)
> {
> Evas_GL_Image *gim = image;
> Image_Entry *im;
>
>
> --
> Cloud Computing - Latest Buzzword or a Glimpse of the Future?
> This paper surveys cloud computing today: What are the benefits?
> Why are businesses embracing it? What are its payoffs and pitfalls?
> http://www.accelacomm.com/jaw/sdnl/114/51425149/
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits?
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/modules/engines/gl_x11
On 12/14/11 13:55, Vincent Torri wrote:
> this one and the previous one should be backported
>
> Vincent
>
Not sure how to go about that :/ Never did any backporting.
dh
> On Wed, Dec 14, 2011 at 7:52 PM, Enlightenment SVN
> wrote:
>> Log:
>> Evas: Gl_X11: Fix typo? for __UNUSED__ param.
>>
>>
>>
>> Author: devilhorns
>> Date: 2011-12-14 10:52:42 -0800 (Wed, 14 Dec 2011)
>> New Revision: 66224
>> Trac: http://trac.enlightenment.org/e/changeset/66224
>>
>> Modified:
>> trunk/evas/src/modules/engines/gl_x11/evas_engine.c
>>
>> Modified: trunk/evas/src/modules/engines/gl_x11/evas_engine.c
>> ===
>> --- trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2011-12-14 18:44:20
>> UTC (rev 66223)
>> +++ trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2011-12-14 18:52:42
>> UTC (rev 66224)
>> @@ -3703,7 +3703,7 @@
>> }
>>
>> static Eina_Bool
>> -eng_image_can_region_get(void *data__UNUSED__, void *image)
>> +eng_image_can_region_get(void *data __UNUSED__, void *image)
>> {
>> Evas_GL_Image *gim = image;
>> Image_Entry *im;
>>
>>
--
Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits?
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/modules/engines/gl_x11
On 12/14/11 13:59, Vincent Torri wrote:
> On Wed, Dec 14, 2011 at 7:58 PM, Christopher Michael
> wrote:
>> On 12/14/11 13:55, Vincent Torri wrote:
>>>
>>> this one and the previous one should be backported
>>>
>>> Vincent
>>>
>>
>> Not sure how to go about that :/ Never did any backporting.
>
> just check out the branches, modify them and commit. they are in
> e/branches/, not in e/trunk/
>
> Vincent
>
Ok, I checked both evas 1.0 and 1.1, but this function does not exist in
either so there is no 'changes' to backport.
dh
>>
>> dh
>>
>>> On Wed, Dec 14, 2011 at 7:52 PM, Enlightenment SVN
>>> wrote:
Log:
Evas: Gl_X11: Fix typo? for __UNUSED__ param.
Author: devilhorns
Date: 2011-12-14 10:52:42 -0800 (Wed, 14 Dec 2011)
New Revision: 66224
Trac: http://trac.enlightenment.org/e/changeset/66224
Modified:
trunk/evas/src/modules/engines/gl_x11/evas_engine.c
Modified: trunk/evas/src/modules/engines/gl_x11/evas_engine.c
===
--- trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2011-12-14
18:44:20 UTC (rev 66223)
+++ trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2011-12-14
18:52:42 UTC (rev 66224)
@@ -3703,7 +3703,7 @@
}
static Eina_Bool
-eng_image_can_region_get(void *data__UNUSED__, void *image)
+eng_image_can_region_get(void *data __UNUSED__, void *image)
{
Evas_GL_Image *gim = image;
Image_Entry *im;
>>
>>
>
--
Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits?
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/modules/engines/software_generic
Ho thanks, yeah it's a typo. Good job !
2011/12/14 Enlightenment SVN
> Log:
> Evas: Software_Generic: Fix typo? for __UNUSED__.
>
>
>
> Author: devilhorns
> Date: 2011-12-14 10:27:29 -0800 (Wed, 14 Dec 2011)
> New Revision: 66222
> Trac: http://trac.enlightenment.org/e/changeset/66222
>
> Modified:
> trunk/evas/src/modules/engines/software_generic/evas_engine.c
>
> Modified: trunk/evas/src/modules/engines/software_generic/evas_engine.c
> ===
> --- trunk/evas/src/modules/engines/software_generic/evas_engine.c
> 2011-12-14 17:37:43 UTC (rev 66221)
> +++ trunk/evas/src/modules/engines/software_generic/evas_engine.c
> 2011-12-14 18:27:29 UTC (rev 66222)
> @@ -259,7 +259,7 @@
> }
>
> static Eina_Bool
> -eng_image_can_region_get(void *data__UNUSED__, void *image)
> +eng_image_can_region_get(void *data __UNUSED__, void *image)
> {
>Image_Entry *im;
>if (!image) return EINA_FALSE;
>
>
>
> --
> Cloud Computing - Latest Buzzword or a Glimpse of the Future?
> This paper surveys cloud computing today: What are the benefits?
> Why are businesses embracing it? What are its payoffs and pitfalls?
> http://www.accelacomm.com/jaw/sdnl/114/51425149/
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
--
Michaël Bouchaud
--
Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits?
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/modules/engines/gl_x11
no no no, They don't need to be backported it's since evas 1.2
2011/12/14 Christopher Michael
> On 12/14/11 13:59, Vincent Torri wrote:
> > On Wed, Dec 14, 2011 at 7:58 PM, Christopher Michael
> > wrote:
> >> On 12/14/11 13:55, Vincent Torri wrote:
> >>>
> >>> this one and the previous one should be backported
> >>>
> >>> Vincent
> >>>
> >>
> >> Not sure how to go about that :/ Never did any backporting.
> >
> > just check out the branches, modify them and commit. they are in
> > e/branches/, not in e/trunk/
> >
> > Vincent
> >
> Ok, I checked both evas 1.0 and 1.1, but this function does not exist in
> either so there is no 'changes' to backport.
>
> dh
>
> >>
> >> dh
> >>
> >>> On Wed, Dec 14, 2011 at 7:52 PM, Enlightenment SVN
> >>> wrote:
>
> Log:
> Evas: Gl_X11: Fix typo? for __UNUSED__ param.
>
>
>
> Author: devilhorns
> Date: 2011-12-14 10:52:42 -0800 (Wed, 14 Dec 2011)
> New Revision: 66224
> Trac: http://trac.enlightenment.org/e/changeset/66224
>
> Modified:
> trunk/evas/src/modules/engines/gl_x11/evas_engine.c
>
> Modified: trunk/evas/src/modules/engines/gl_x11/evas_engine.c
> ===
> --- trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2011-12-14
> 18:44:20 UTC (rev 66223)
> +++ trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2011-12-14
> 18:52:42 UTC (rev 66224)
> @@ -3703,7 +3703,7 @@
> }
>
> static Eina_Bool
> -eng_image_can_region_get(void *data__UNUSED__, void *image)
> +eng_image_can_region_get(void *data __UNUSED__, void *image)
> {
> Evas_GL_Image *gim = image;
> Image_Entry *im;
>
>
> >>
> >>
> >
>
>
>
> --
> Cloud Computing - Latest Buzzword or a Glimpse of the Future?
> This paper surveys cloud computing today: What are the benefits?
> Why are businesses embracing it? What are its payoffs and pitfalls?
> http://www.accelacomm.com/jaw/sdnl/114/51425149/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Michaël Bouchaud
--
Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits?
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/modules/engines/gl_x11
Ahh, then I need (or someone can) to fix the doxy on the 2 new Evas functions I
added for setting/getting framepsace. They are doxy'd @ 1.1.0 (my bad, I don't
follow rev versions much ;) )
dh
- Original Message -
From: "michael bouchaud"
To: "Enlightenment developer list"
Sent: Wednesday, December 14, 2011 4:28:56 PM
Subject: Re: [E-devel] E SVN: devilhorns trunk/evas/src/modules/engines/gl_x11
no no no, They don't need to be backported it's since evas 1.2
2011/12/14 Christopher Michael
> On 12/14/11 13:59, Vincent Torri wrote:
> > On Wed, Dec 14, 2011 at 7:58 PM, Christopher Michael
> > wrote:
> >> On 12/14/11 13:55, Vincent Torri wrote:
> >>>
> >>> this one and the previous one should be backported
> >>>
> >>> Vincent
> >>>
> >>
> >> Not sure how to go about that :/ Never did any backporting.
> >
> > just check out the branches, modify them and commit. they are in
> > e/branches/, not in e/trunk/
> >
> > Vincent
> >
> Ok, I checked both evas 1.0 and 1.1, but this function does not exist in
> either so there is no 'changes' to backport.
>
> dh
>
> >>
> >> dh
> >>
> >>> On Wed, Dec 14, 2011 at 7:52 PM, Enlightenment SVN
> >>> wrote:
> >>>>
> >>>> Log:
> >>>> Evas: Gl_X11: Fix typo? for __UNUSED__ param.
> >>>>
> >>>>
> >>>>
> >>>> Author: devilhorns
> >>>> Date: 2011-12-14 10:52:42 -0800 (Wed, 14 Dec 2011)
> >>>> New Revision: 66224
> >>>> Trac: http://trac.enlightenment.org/e/changeset/66224
> >>>>
> >>>> Modified:
> >>>> trunk/evas/src/modules/engines/gl_x11/evas_engine.c
> >>>>
> >>>> Modified: trunk/evas/src/modules/engines/gl_x11/evas_engine.c
> >>>> ===
> >>>> --- trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2011-12-14
> >>>> 18:44:20 UTC (rev 66223)
> >>>> +++ trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2011-12-14
> >>>> 18:52:42 UTC (rev 66224)
> >>>> @@ -3703,7 +3703,7 @@
> >>>> }
> >>>>
> >>>> static Eina_Bool
> >>>> -eng_image_can_region_get(void *data__UNUSED__, void *image)
> >>>> +eng_image_can_region_get(void *data __UNUSED__, void *image)
> >>>> {
> >>>> Evas_GL_Image *gim = image;
> >>>> Image_Entry *im;
> >>>>
> >>>>
> >>
> >>
> >
>
>
>
> --
>
> Cloud Computing - Latest Buzzword or a Glimpse of the Future?
> This paper surveys cloud computing today: What are the benefits?
> Why are businesses embracing it? What are its payoffs and pitfalls?
> http://www.accelacomm.com/jaw/sdnl/114/51425149/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Michaël Bouchaud
--
Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits?
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits?
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/modules/engines/gl_x11
On Wed, Dec 14, 2011 at 11:40 PM, wrote:
> Ahh, then I need (or someone can) to fix the doxy on the 2 new Evas functions
> I added for setting/getting framepsace. They are doxy'd @ 1.1.0 (my bad, I
> don't follow rev versions much ;) )
@since 1.2 actually, if the function does not exist in 1.1
Vincent
>
> dh
>
> - Original Message -
> From: "michael bouchaud"
> To: "Enlightenment developer list"
> Sent: Wednesday, December 14, 2011 4:28:56 PM
> Subject: Re: [E-devel] E SVN: devilhorns trunk/evas/src/modules/engines/gl_x11
>
> no no no, They don't need to be backported it's since evas 1.2
>
> 2011/12/14 Christopher Michael
>
>> On 12/14/11 13:59, Vincent Torri wrote:
>> > On Wed, Dec 14, 2011 at 7:58 PM, Christopher Michael
>> > wrote:
>> >> On 12/14/11 13:55, Vincent Torri wrote:
>> >>>
>> >>> this one and the previous one should be backported
>> >>>
>> >>> Vincent
>> >>>
>> >>
>> >> Not sure how to go about that :/ Never did any backporting.
>> >
>> > just check out the branches, modify them and commit. they are in
>> > e/branches/, not in e/trunk/
>> >
>> > Vincent
>> >
>> Ok, I checked both evas 1.0 and 1.1, but this function does not exist in
>> either so there is no 'changes' to backport.
>>
>> dh
>>
>> >>
>> >> dh
>> >>
>> >>> On Wed, Dec 14, 2011 at 7:52 PM, Enlightenment SVN
>> >>> wrote:
>> >>>>
>> >>>> Log:
>> >>>> Evas: Gl_X11: Fix typo? for __UNUSED__ param.
>> >>>>
>> >>>>
>> >>>>
>> >>>> Author: devilhorns
>> >>>> Date: 2011-12-14 10:52:42 -0800 (Wed, 14 Dec 2011)
>> >>>> New Revision: 66224
>> >>>> Trac: http://trac.enlightenment.org/e/changeset/66224
>> >>>>
>> >>>> Modified:
>> >>>> trunk/evas/src/modules/engines/gl_x11/evas_engine.c
>> >>>>
>> >>>> Modified: trunk/evas/src/modules/engines/gl_x11/evas_engine.c
>> >>>> ===
>> >>>> --- trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2011-12-14
>> >>>> 18:44:20 UTC (rev 66223)
>> >>>> +++ trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2011-12-14
>> >>>> 18:52:42 UTC (rev 66224)
>> >>>> @@ -3703,7 +3703,7 @@
>> >>>> }
>> >>>>
>> >>>> static Eina_Bool
>> >>>> -eng_image_can_region_get(void *data__UNUSED__, void *image)
>> >>>> +eng_image_can_region_get(void *data __UNUSED__, void *image)
>> >>>> {
>> >>>> Evas_GL_Image *gim = image;
>> >>>> Image_Entry *im;
>> >>>>
>> >>>>
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> Cloud Computing - Latest Buzzword or a Glimpse of the Future?
>> This paper surveys cloud computing today: What are the benefits?
>> Why are businesses embracing it? What are its payoffs and pitfalls?
>> http://www.accelacomm.com/jaw/sdnl/114/51425149/
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>
>
>
> --
> Michaël Bouchaud
> --
> Cloud Computing - Latest Buzzword or a Glimpse of the Future?
> This paper surveys cloud computing today: What are the benefits?
> Why are businesses embracing it? What are its payoffs and pitfalls?
> http://www.accelacomm.com/jaw/sdnl/114/51425149/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> --
> Cloud Computing - Latest Buzzword or a Glimpse of the Future?
> This paper surveys cloud computing today: What are the benefits?
> Why are businesses embracing it? What are its payoffs and pitfalls?
> http://www.accelacomm.com/jaw/sdnl/114/51425149/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits?
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/modules/engines/gl_x11
On Wed, 14 Dec 2011 23:45:01 +0100 Vincent Torri said:
> On Wed, Dec 14, 2011 at 11:40 PM, wrote:
> > Ahh, then I need (or someone can) to fix the doxy on the 2 new Evas
> > functions I added for setting/getting framepsace. They are doxy'd @ 1.1.0
> > (my bad, I don't follow rev versions much ;) )
>
> @since 1.2 actually, if the function does not exist in 1.1
>
> Vincent
its not an api func so it's not exposed and so... it doesnt have docs.. and
doesnt have an @since.
> >
> > dh
> >
> > - Original Message -
> > From: "michael bouchaud"
> > To: "Enlightenment developer list"
> > Sent: Wednesday, December 14,
> > 2011 4:28:56 PM Subject: Re: [E-devel] E SVN: devilhorns
> > trunk/evas/src/modules/engines/gl_x11
> >
> > no no no, They don't need to be backported it's since evas 1.2
> >
> > 2011/12/14 Christopher Michael
> >
> >> On 12/14/11 13:59, Vincent Torri wrote:
> >> > On Wed, Dec 14, 2011 at 7:58 PM, Christopher Michael
> >> > wrote:
> >> >> On 12/14/11 13:55, Vincent Torri wrote:
> >> >>>
> >> >>> this one and the previous one should be backported
> >> >>>
> >> >>> Vincent
> >> >>>
> >> >>
> >> >> Not sure how to go about that :/ Never did any backporting.
> >> >
> >> > just check out the branches, modify them and commit. they are in
> >> > e/branches/, not in e/trunk/
> >> >
> >> > Vincent
> >> >
> >> Ok, I checked both evas 1.0 and 1.1, but this function does not exist in
> >> either so there is no 'changes' to backport.
> >>
> >> dh
> >>
> >> >>
> >> >> dh
> >> >>
> >> >>> On Wed, Dec 14, 2011 at 7:52 PM, Enlightenment SVN
> >> >>> wrote:
> >> >>>>
> >> >>>> Log:
> >> >>>> Evas: Gl_X11: Fix typo? for __UNUSED__ param.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> Author: devilhorns
> >> >>>> Date: 2011-12-14 10:52:42 -0800 (Wed, 14 Dec 2011)
> >> >>>> New Revision: 66224
> >> >>>> Trac: http://trac.enlightenment.org/e/changeset/66224
> >> >>>>
> >> >>>> Modified:
> >> >>>> trunk/evas/src/modules/engines/gl_x11/evas_engine.c
> >> >>>>
> >> >>>> Modified: trunk/evas/src/modules/engines/gl_x11/evas_engine.c
> >> >>>> ===
> >> >>>> --- trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2011-12-14
> >> >>>> 18:44:20 UTC (rev 66223)
> >> >>>> +++ trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2011-12-14
> >> >>>> 18:52:42 UTC (rev 66224)
> >> >>>> @@ -3703,7 +3703,7 @@
> >> >>>> }
> >> >>>>
> >> >>>> static Eina_Bool
> >> >>>> -eng_image_can_region_get(void *data__UNUSED__, void *image)
> >> >>>> +eng_image_can_region_get(void *data __UNUSED__, void *image)
> >> >>>> {
> >> >>>> Evas_GL_Image *gim = image;
> >> >>>> Image_Entry *im;
> >> >>>>
> >> >>>>
> >> >>
> >> >>
> >> >
> >>
> >>
> >>
> >> --
> >> Cloud Computing - Latest Buzzword or a Glimpse of the Future?
> >> This paper surveys cloud computing today: What are the benefits?
> >> Why are businesses embracing it? What are its payoffs and pitfalls?
> >> http://www.accelacomm.com/jaw/sdnl/114/51425149/
> >> ___
> >> enlightenment-devel mailing list
> >> enlightenment-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>
> >
> >
> >
> > --
> > Michaël Bouchaud
> > --
> > Cloud Computing - Latest Buzzword or a Glimpse of the Future?
> > This paper surveys cloud computing today: What are the benefits?
> > Why are businesses embracing it? What are its p
Re: [E-devel] E SVN: devilhorns trunk/evas/src/modules/engines/gl_x11
On Wed, 14 Dec 2011 13:58:13 -0500 Christopher Michael
said:
> On 12/14/11 13:55, Vincent Torri wrote:
> > this one and the previous one should be backported
> >
> > Vincent
> >
>
> Not sure how to go about that :/ Never did any backporting.
apply same change to the evas-1.1 evas tree under branches in svn (below trunk
there is also branches and tags to svn update from that base and look in
branches)
> dh
>
> > On Wed, Dec 14, 2011 at 7:52 PM, Enlightenment SVN
> > wrote:
> >> Log:
> >> Evas: Gl_X11: Fix typo? for __UNUSED__ param.
> >>
> >>
> >>
> >> Author: devilhorns
> >> Date: 2011-12-14 10:52:42 -0800 (Wed, 14 Dec 2011)
> >> New Revision: 66224
> >> Trac: http://trac.enlightenment.org/e/changeset/66224
> >>
> >> Modified:
> >> trunk/evas/src/modules/engines/gl_x11/evas_engine.c
> >>
> >> Modified: trunk/evas/src/modules/engines/gl_x11/evas_engine.c
> >> ===
> >> --- trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2011-12-14
> >> 18:44:20 UTC (rev 66223) +++
> >> trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2011-12-14 18:52:42
> >> UTC (rev 66224) @@ -3703,7 +3703,7 @@ }
> >>
> >> static Eina_Bool
> >> -eng_image_can_region_get(void *data__UNUSED__, void *image)
> >> +eng_image_can_region_get(void *data __UNUSED__, void *image)
> >> {
> >> Evas_GL_Image *gim = image;
> >> Image_Entry *im;
> >>
> >>
>
>
>
> --
> Cloud Computing - Latest Buzzword or a Glimpse of the Future?
> This paper surveys cloud computing today: What are the benefits?
> Why are businesses embracing it? What are its payoffs and pitfalls?
> http://www.accelacomm.com/jaw/sdnl/114/51425149/
> ___
> 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
--
10 Tips for Better Server Consolidation
Server virtualization is being driven by many needs.
But none more important than the need to reduce IT complexity
while improving strategic productivity. Learn More!
http://www.accelacomm.com/jaw/sdnl/114/51507609/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/modules/engines/gl_x11
Right...thanks what I asked. Rather than bitch, it's easier to fix :P
dh :P :P :P
On 12/14/11 17:45, Vincent Torri wrote:
> On Wed, Dec 14, 2011 at 11:40 PM, wrote:
>> Ahh, then I need (or someone can) to fix the doxy on the 2 new Evas
>> functions I added for setting/getting framepsace. They are doxy'd @ 1.1.0
>> (my bad, I don't follow rev versions much ;) )
>
> @since 1.2 actually, if the function does not exist in 1.1
>
> Vincent
>
>>
>> dh
>>
>> - Original Message -
>> From: "michael bouchaud"
>> To: "Enlightenment developer list"
>> Sent: Wednesday, December 14, 2011 4:28:56 PM
>> Subject: Re: [E-devel] E SVN: devilhorns
>> trunk/evas/src/modules/engines/gl_x11
>>
>> no no no, They don't need to be backported it's since evas 1.2
>>
>> 2011/12/14 Christopher Michael
>>
>>> On 12/14/11 13:59, Vincent Torri wrote:
>>>> On Wed, Dec 14, 2011 at 7:58 PM, Christopher Michael
>>>> wrote:
>>>>> On 12/14/11 13:55, Vincent Torri wrote:
>>>>>>
>>>>>> this one and the previous one should be backported
>>>>>>
>>>>>> Vincent
>>>>>>
>>>>>
>>>>> Not sure how to go about that :/ Never did any backporting.
>>>>
>>>> just check out the branches, modify them and commit. they are in
>>>> e/branches/, not in e/trunk/
>>>>
>>>> Vincent
>>>>
>>> Ok, I checked both evas 1.0 and 1.1, but this function does not exist in
>>> either so there is no 'changes' to backport.
>>>
>>> dh
>>>
>>>>>
>>>>> dh
>>>>>
>>>>>> On Wed, Dec 14, 2011 at 7:52 PM, Enlightenment SVN
>>>>>> wrote:
>>>>>>>
>>>>>>> Log:
>>>>>>> Evas: Gl_X11: Fix typo? for __UNUSED__ param.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Author: devilhorns
>>>>>>> Date: 2011-12-14 10:52:42 -0800 (Wed, 14 Dec 2011)
>>>>>>> New Revision: 66224
>>>>>>> Trac: http://trac.enlightenment.org/e/changeset/66224
>>>>>>>
>>>>>>> Modified:
>>>>>>> trunk/evas/src/modules/engines/gl_x11/evas_engine.c
>>>>>>>
>>>>>>> Modified: trunk/evas/src/modules/engines/gl_x11/evas_engine.c
>>>>>>> ===
>>>>>>> --- trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2011-12-14
>>>>>>> 18:44:20 UTC (rev 66223)
>>>>>>> +++ trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2011-12-14
>>>>>>> 18:52:42 UTC (rev 66224)
>>>>>>> @@ -3703,7 +3703,7 @@
>>>>>>> }
>>>>>>>
>>>>>>> static Eina_Bool
>>>>>>> -eng_image_can_region_get(void *data__UNUSED__, void *image)
>>>>>>> +eng_image_can_region_get(void *data __UNUSED__, void *image)
>>>>>>> {
>>>>>>> Evas_GL_Image *gim = image;
>>>>>>> Image_Entry *im;
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Cloud Computing - Latest Buzzword or a Glimpse of the Future?
>>> This paper surveys cloud computing today: What are the benefits?
>>> Why are businesses embracing it? What are its payoffs and pitfalls?
>>> http://www.accelacomm.com/jaw/sdnl/114/51425149/
>>> ___
>>> enlightenment-devel mailing list
>>> enlightenment-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>>
>>
>>
>>
>> --
>> Michaël Bouchaud
>> --
>> Cloud Computing - Latest Buzzword or a Glimpse of the Future?
>> This paper surveys cloud computing today: What are the benefits?
>> Why are businesses embracing it? What are its payoffs and pitfalls?
>> http://www.accelacomm.com/jaw/sdnl/114/51425149/
>> ___
>> enlightenment-devel mailing list
>&
Re: [E-devel] E SVN: devilhorns trunk/evas/src/modules/engines/gl_x11
Why not move eglMakeCurrent? So you keep one if.
S.
> Log:
> Evas (gl_x11): We cannot call eglMakeCurrent if we have already called
> eglTerminate prior (eg: eglTerminate was in the wrong place here).
>
>
>
> Author: devilhorns
> Date: 2012-01-11 22:06:07 -0800 (Wed, 11 Jan 2012)
> New Revision: 67119
> Trac: http://trac.enlightenment.org/e/changeset/67119
>
> Modified:
> trunk/evas/src/modules/engines/gl_x11/evas_x_main.c
>
> Modified: trunk/evas/src/modules/engines/gl_x11/evas_x_main.c
> ===
> --- trunk/evas/src/modules/engines/gl_x11/evas_x_main.c 2012-01-12
> 05:36:47 UTC (rev 67118)
> +++ trunk/evas/src/modules/engines/gl_x11/evas_x_main.c 2012-01-12
> 06:06:07 UTC (rev 67119)
> @@ -534,10 +534,10 @@
> if (ref == 0)
> {
> if (context) eglDestroyContext(gw->egl_disp, context);
> -eglTerminate(gw->egl_disp);
> context = EGL_NO_CONTEXT;
> }
> eglMakeCurrent(gw->egl_disp, EGL_NO_SURFACE, EGL_NO_SURFACE,
> EGL_NO_CONTEXT);
> + if (ref == 0) eglTerminate(gw->egl_disp);
> #else
> if (gw->glxwin) glXDestroyWindow(gw->disp, gw->glxwin);
> if (ref == 0)
>
>
> --
> RSA(R) Conference 2012
> Mar 27 - Feb 2
> Save $400 by Jan. 27
> Register now!
> http://p.sf.net/sfu/rsa-sfdev2dev2
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/modules/engines/gl_x11
Suppose it could have went either way...If you think it would really be
better by moving the MakeCurrent, then I'll do it :)
dh
On 01/12/12 06:46, s...@tango.flipp.net wrote:
> Why not move eglMakeCurrent? So you keep one if.
>
> S.
>
>> Log:
>> Evas (gl_x11): We cannot call eglMakeCurrent if we have already called
>>eglTerminate prior (eg: eglTerminate was in the wrong place here).
>>
>>
>>
>> Author: devilhorns
>> Date: 2012-01-11 22:06:07 -0800 (Wed, 11 Jan 2012)
>> New Revision: 67119
>> Trac: http://trac.enlightenment.org/e/changeset/67119
>>
>> Modified:
>>trunk/evas/src/modules/engines/gl_x11/evas_x_main.c
>>
>> Modified: trunk/evas/src/modules/engines/gl_x11/evas_x_main.c
>> ===
>> --- trunk/evas/src/modules/engines/gl_x11/evas_x_main.c 2012-01-12
>> 05:36:47 UTC (rev 67118)
>> +++ trunk/evas/src/modules/engines/gl_x11/evas_x_main.c 2012-01-12
>> 06:06:07 UTC (rev 67119)
>> @@ -534,10 +534,10 @@
>> if (ref == 0)
>>{
>> if (context) eglDestroyContext(gw->egl_disp, context);
>> -eglTerminate(gw->egl_disp);
>> context = EGL_NO_CONTEXT;
>>}
>> eglMakeCurrent(gw->egl_disp, EGL_NO_SURFACE, EGL_NO_SURFACE,
>> EGL_NO_CONTEXT);
>> + if (ref == 0) eglTerminate(gw->egl_disp);
>> #else
>> if (gw->glxwin) glXDestroyWindow(gw->disp, gw->glxwin);
>> if (ref == 0)
>>
>>
>> --
>> RSA(R) Conference 2012
>> Mar 27 - Feb 2
>> Save $400 by Jan. 27
>> Register now!
>> http://p.sf.net/sfu/rsa-sfdev2dev2
>> ___
>> enlightenment-svn mailing list
>> enlightenment-...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>>
>
>
>
> --
> RSA(R) Conference 2012
> Mar 27 - Feb 2
> Save $400 by Jan. 27
> Register now!
> http://p.sf.net/sfu/rsa-sfdev2dev2
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/evas/src/modules/engines/gl_x11
Done. Thanks for the suggestion :)
dh
On 01/12/12 07:11, Christopher Michael wrote:
> Suppose it could have went either way...If you think it would really be
> better by moving the MakeCurrent, then I'll do it :)
>
> dh
>
> On 01/12/12 06:46, s...@tango.flipp.net wrote:
>> Why not move eglMakeCurrent? So you keep one if.
>>
>> S.
>>
>>> Log:
>>> Evas (gl_x11): We cannot call eglMakeCurrent if we have already called
>>> eglTerminate prior (eg: eglTerminate was in the wrong place here).
>>>
>>>
>>>
>>> Author: devilhorns
>>> Date: 2012-01-11 22:06:07 -0800 (Wed, 11 Jan 2012)
>>> New Revision: 67119
>>> Trac: http://trac.enlightenment.org/e/changeset/67119
>>>
>>> Modified:
>>> trunk/evas/src/modules/engines/gl_x11/evas_x_main.c
>>>
>>> Modified: trunk/evas/src/modules/engines/gl_x11/evas_x_main.c
>>> ===
>>> --- trunk/evas/src/modules/engines/gl_x11/evas_x_main.c 2012-01-12
>>> 05:36:47 UTC (rev 67118)
>>> +++ trunk/evas/src/modules/engines/gl_x11/evas_x_main.c 2012-01-12
>>> 06:06:07 UTC (rev 67119)
>>> @@ -534,10 +534,10 @@
>>> if (ref == 0)
>>> {
>>> if (context) eglDestroyContext(gw->egl_disp, context);
>>> - eglTerminate(gw->egl_disp);
>>> context = EGL_NO_CONTEXT;
>>> }
>>> eglMakeCurrent(gw->egl_disp, EGL_NO_SURFACE, EGL_NO_SURFACE,
>>> EGL_NO_CONTEXT);
>>> + if (ref == 0) eglTerminate(gw->egl_disp);
>>> #else
>>> if (gw->glxwin) glXDestroyWindow(gw->disp, gw->glxwin);
>>> if (ref == 0)
>>>
>>>
>>> --
>>>
>>> RSA(R) Conference 2012
>>> Mar 27 - Feb 2
>>> Save $400 by Jan. 27
>>> Register now!
>>> http://p.sf.net/sfu/rsa-sfdev2dev2
>>> ___
>>> enlightenment-svn mailing list
>>> enlightenment-...@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>>>
>>
>>
>>
>> --
>>
>> RSA(R) Conference 2012
>> Mar 27 - Feb 2
>> Save $400 by Jan. 27
>> Register now!
>> http://p.sf.net/sfu/rsa-sfdev2dev2
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
