I have reduced access to my computer at the moment but I'll do what I can.
2012/5/11 Davide Andreoli <dave@...>:
> Forwarding for who don't follow the commit list:
>
>
> Log:
> Background object revised, now match the C api.
>
> CALL FOR HELP:
> Ok we need to do this work for each elm widget, it's a really
> annoing work to do, but it's also very easy.
>
> Someone want to help me in this revision work? It will take months for me
> to do alone
>
> If you are intrested I'm using the c_elementary.pxd file as index,
> I will put a (DONE) on widget that are...well..done :)
>
> davemds
>

On Fri, 11 May 2012 16:07:36 -0400
Art B <whinemore@...> wrote:
> I can't seem to figure/understand how to modify the fonts(name or size)
> trough my elm C client-code. I can do this easily with an edje TEXTBLOCK
> object. But then I miss out on anchors for example.
>
> I would appreciate greatly if someone could explain how to do this with
> elementary for me. A code example would suffice also.
>
>
> Thank you.
check trunk/elementary/src/bin/test_entry.c ?

I can't seem to figure/understand how to modify the fonts(name or size)
trough my elm C client-code. I can do this easily with an edje TEXTBLOCK
object. But then I miss out on anchors for example.
I would appreciate greatly if someone could explain how to do this with
elementary for me. A code example would suffice also.
Thank you.

On Fri, May 11, 2012 at 5:26 AM, Raphael Kubo da Costa
<rakuco@...> wrote:
> Hey there.
>
> I was trying to build ecore earlier today and apparently the libgcrypt
> CFLAGS and linker flags were not being passed as expected (GnuTLS
> support is enabled).
>
> In the end, it looks like the code in ecore_check_options.m4 was failing
> here:
>
> checking for libgcrypt-config... /usr/local/bin/libgcrypt-config
> checking for libgcrypt... yes
> ./configure: TLS_CFLAGS+= -I/usr/local/include: not found
> ./configure: TLS_LIBS+= -L/usr/local/lib -lgcrypt -lgpg-error: not
> found
>
> The attached patch solves the issue by not using '+=' to append the
> values to TLS_{CFLAGS,LIBS}. I thought of using AS_VAR_APPEND, but I
> don't know if there are autoconf versions we are supposed to support
> which do not have that macro.
>
> The patch should also apply cleanly to the 1.0, 1.1 and 1.2
> branches. Please let me know if there should be a NEWS/ChangeLog entry.
in svn, thanks. I do not have the other branches, so if someone can do it...
Vincent

On Fri, May 11, 2012 at 8:10 AM, Cedric BAIL <cedric.bail@...> wrote:
> On Fri, May 11, 2012 at 2:36 PM, Daniel Juyung Seo <seojuyung2@...> wrote:
>> Yes eio came after edje release. So for those who do not use eio, this
>> breaks consistency.
>> So edje_watch build should be optional.
>
> Eio is released and API/ABI is stable. We can now use it in more
> relevant place. If we are locked down to the library we used as 1.0
> dependencies, then we would be very limited in the future. So I
> clearly disagree on your argument. As people want to not build edje
> against eio, then whatever they want.
as I said : the lib and edje_watch should have the same dep wrt eio :
optional or mandatory. It should not be mixed.
Vincent

Oh you're right. This is not edje 1.0. So ok to me.
Daniel Juyung Seo (SeoZ)
On Fri, May 11, 2012 at 3:10 PM, Cedric BAIL <cedric.bail@...> wrote:
> On Fri, May 11, 2012 at 2:36 PM, Daniel Juyung Seo <seojuyung2@...> wrote:
>> Yes eio came after edje release. So for those who do not use eio, this
>> breaks consistency.
>> So edje_watch build should be optional.
>
> Eio is released and API/ABI is stable. We can now use it in more
> relevant place. If we are locked down to the library we used as 1.0
> dependencies, then we would be very limited in the future. So I
> clearly disagree on your argument. As people want to not build edje
> against eio, then whatever they want.
> --
> Cedric BAIL
>
> ------------------------------------------------------------------------------
> 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@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

On Fri, May 11, 2012 at 2:36 PM, Daniel Juyung Seo <seojuyung2@...> wrote:
> Yes eio came after edje release. So for those who do not use eio, this
> breaks consistency.
> So edje_watch build should be optional.
Eio is released and API/ABI is stable. We can now use it in more
relevant place. If we are locked down to the library we used as 1.0
dependencies, then we would be very limited in the future. So I
clearly disagree on your argument. As people want to not build edje
against eio, then whatever they want.
--
Cedric BAIL

Yes eio came after edje release. So for those who do not use eio, this
breaks consistency.
So edje_watch build should be optional.
Daniel Juyung Seo (SeoZ)
On Fri, May 11, 2012 at 12:50 PM, Vincent Torri <vincent.torri@...> wrote:
> On Fri, May 11, 2012 at 2:20 AM, Cedric BAIL <cedric.bail@...> wrote:
>> On Fri, May 11, 2012 at 12:37 AM, Michael Blumenkrantz
>> <michael.blumenkrantz@...> wrote:
>>> On Thu, 10 May 2012 16:39:48 +0300
>>> Tom Hacohen <tom.hacohen@...> wrote:
>>>> Dear Cedric,
>>>>
>>>> You ruined my life. Seriously, I don't want Eio and it's pissing me off.
>>>> :) It's only a dep for edje_watch, so just if you don't detect eio,
>>>> don't build edje_watch.
>>>>
>>>> Vincent said he'll take a look tonight, but please if you see it's not
>>>> fixed by tomorrow, fix it.
>>>
>>> I vote we keep it. Anything that ruins Tom's life must necessarily improve my
>>> life. This feature seems like an absolute requirement.
>>
>> Sounds the same to me ! More seriously, I did that on purpose, so that
>> most people will build with eio dep in. If you don't want it just
>> disable the build of edje_watch. That should do the work.
>
> well, you did something that is inconsistent : eio is optional for
> the library, but mandatory for edje watch
>
> Vincent
>
> ------------------------------------------------------------------------------
> 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@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

On Fri, May 11, 2012 at 2:20 AM, Cedric BAIL <cedric.bail@...> wrote:
> On Fri, May 11, 2012 at 12:37 AM, Michael Blumenkrantz
> <michael.blumenkrantz@...> wrote:
>> On Thu, 10 May 2012 16:39:48 +0300
>> Tom Hacohen <tom.hacohen@...> wrote:
>>> Dear Cedric,
>>>
>>> You ruined my life. Seriously, I don't want Eio and it's pissing me off.
>>> :) It's only a dep for edje_watch, so just if you don't detect eio,
>>> don't build edje_watch.
>>>
>>> Vincent said he'll take a look tonight, but please if you see it's not
>>> fixed by tomorrow, fix it.
>>
>> I vote we keep it. Anything that ruins Tom's life must necessarily improve my
>> life. This feature seems like an absolute requirement.
>
> Sounds the same to me ! More seriously, I did that on purpose, so that
> most people will build with eio dep in. If you don't want it just
> disable the build of edje_watch. That should do the work.
well, you did something that is inconsistent : eio is optional for
the library, but mandatory for edje watch
Vincent

Hey there.
I was trying to build ecore earlier today and apparently the libgcrypt
CFLAGS and linker flags were not being passed as expected (GnuTLS
support is enabled).
In the end, it looks like the code in ecore_check_options.m4 was failing
here:
checking for libgcrypt-config... /usr/local/bin/libgcrypt-config
checking for libgcrypt... yes
./configure: TLS_CFLAGS+= -I/usr/local/include: not found
./configure: TLS_LIBS+= -L/usr/local/lib -lgcrypt -lgpg-error: not
found
The attached patch solves the issue by not using '+=' to append the
values to TLS_{CFLAGS,LIBS}. I thought of using AS_VAR_APPEND, but I
don't know if there are autoconf versions we are supposed to support
which do not have that macro.
The patch should also apply cleanly to the 1.0, 1.1 and 1.2
branches. Please let me know if there should be a NEWS/ChangeLog entry.

this has been the case for a while, but I was too busy to report it.
https://github.com/zmike/shotgun/blob/master/src/bin/contact.c
contact_resource_menu_setup()
the variable 'radio', despite only being explicitly written to one time, fails
the elm widget name check in elm_radio_value_set() at the end of the function.
this was not always the case, to the best of my knowledge.
I blame glima because he's on a vacation^Wbusiness trip.

On Fri, May 11, 2012 at 12:37 AM, Michael Blumenkrantz
<michael.blumenkrantz@...> wrote:
> On Thu, 10 May 2012 16:39:48 +0300
> Tom Hacohen <tom.hacohen@...> wrote:
>> Dear Cedric,
>>
>> You ruined my life. Seriously, I don't want Eio and it's pissing me off.
>> :) It's only a dep for edje_watch, so just if you don't detect eio,
>> don't build edje_watch.
>>
>> Vincent said he'll take a look tonight, but please if you see it's not
>> fixed by tomorrow, fix it.
>
> I vote we keep it. Anything that ruins Tom's life must necessarily improve my
> life. This feature seems like an absolute requirement.
Sounds the same to me ! More seriously, I did that on purpose, so that
most people will build with eio dep in. If you don't want it just
disable the build of edje_watch. That should do the work.
--
Cedric BAIL