Re: [E-devel] Changing the E Menu

[Mike Blumenkrantz]

On Fri, 18 Mar 2011 01:56:30 -0500
Jeff Hoogland  wrote:

> When will the info be shared with those of us kept away from cebit?
> 
> ~Jeff
> 
> On Fri, Mar 18, 2011 at 1:55 AM, Mike Blumenkrantz wrote:
> 
> > On Fri, 18 Mar 2011 01:46:43 -0500
> > Jeff Hoogland  wrote:
> >
> > > All this talk about holding up the E17 release - was there a memo sent
> > out
> > > that I missed? Has a targeted release date been set?
> > >
> > > ~Jeff Hoogland
> > >
> > > On Fri, Mar 18, 2011 at 1:22 AM, Carsten Haitzler  > >wrote:
> > >
> > > > On Thu, 17 Mar 2011 11:46:31 -0500 Jeff Hoogland
> > 
> > > > said:
> > > >
> > > > reality is.. it's not going to become some circular menu or pie menu or
> > > > anything else... because it's not needed and i am not going to hold up
> > e17
> > > > release for a "rewrite of the start menu". it stays as-is. maybe we can
> > > > re-org
> > > > some items, but it needs to stay.
> > > >
> > > > > So back to the main e menu... This is a bit of a drastic change, but
> > I
> > > > > really like. Gives a very sleek feeling - a "fan" menu. Some mock ups
> > one
> > > > of
> > > > > my artists did:
> > > > >
> > > > > Static:
> > > > > http://i.imgur.com/VhDxz.png
> > > > >
> > > > > Semi Animate:
> > > > > http://dl.dropbox.com/u/12757360/out%201.gif
> > > > >
> > > > > Anyone else like this?
> > > > > Cheers,
> > > > > ~Jeff Hoogland
> > > > >
> > > > > On Wed, Mar 16, 2011 at 8:19 PM, hannes.janet...@gmail.com <
> > > > > hannes.janet...@googlemail.com> wrote:
> > > > >
> > > > > > On Thu, Mar 17, 2011 at 1:56 AM, Brian 'morlenxus' Miculcy
> > > > > >  wrote:
> > > > > > > On Thu, Mar 17, 2011 at 01:25:15AM +0100,
> > > > hannes.janetzek@gmail.comwrote:
> > > > > > >> On Wed, Mar 16, 2011 at 9:10 PM, Tom Hacohen 
> > wrote:
> > > > > > >> > On Wed, Mar 16, 2011 at 8:56 PM, Cedric BAIL <
> > cedric.b...@free.fr
> > > > >
> > > > > > wrote:
> > > > > > >> >
> > > > > > >> >>  We do have some nice infra that should make it possible to
> > > > include
> > > > > > >> >> gadget directly inside the menu and have some cool stuff like
> > > > that.
> > > > > > >> >> But that require some work and I don't think it should be a
> > > > blocker
> > > > > > >> >> for a release. It could be just and extra module to start and
> > > > later
> > > > > > >> >> moved inside E17 or maybe more inside E18.
> > > > > > >> >>
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > We are talking about reordering stuff, nothing more.
> > > > > > >> >
> > > > > > >>
> > > > > > >> Talking about reordering menus. currently gadget right click
> > shows
> > > > two
> > > > > > items:
> > > > > > >>
> > > > > > >> gadget >
> > > > > > >> shelf>
> > > > > > >>
> > > > > > >> causing one to do the extra step to go the gadget submenu all
> > the
> > > > > > >> time. which is more annoying when one has to move the mouse
> > against
> > > > > > >> the screen edge to reveal the menu. Any objections to fix all
> > gadget
> > > > > > >> right click menus to this layout:
> > > > > > >>
> > > > > > >> gadget settings
> > > > > > >> 
> > > > > > >> -
> > > > > > >> move/resize
> > > > > > >> layout
> > > > > > >> .
> > > > > > >> -
> > > > > > >> shelf>
> > > > > > >>
> > > > > > >>
> > > > > > >> Regards,
> > > > > > >> Hannes
> > > > > > >
> > > > > > > Yes, i think the current gadget menu is well ordered. Let's not
> > > > clutter
> > > > > > it like before.
> > > > > >
> > > > > > ok then what about:
> > > > > >
> > > > > > Settings
> > > > > > [gadget specific actions:]
> > > > > > 'add item'
> > > > > > 'contents'
> > > > > > --
> > > > > > Gadget Ibar   >
> > > > > > Shelf Settings   >
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Hannes
> > > > > >
> > > > > >
> > > > > > Also check the ibar menu, this is more clearer as when putting
> > > > > > everything at the top level. Let's try to really make the window
> > menu
> > > > > > more simpler. For example there is not much sense to have the
> > minimise
> > > > > > action at the top level as it's mostly available via border
> > buttons. I
> > > > > > will send a new window menu tree proposal later today, just need
> > some
> > > > > > sleep now...
> > > > > > >
> > > > > > > Kind regards,
> > > > > > > Brian
> > > > > > >>
> > > > > > >>
> > > > > > >> > --
> > > > > > >> > Tom.
> > > > > > >> >
> > > > > >
> > cebit.
> >
> > --
> > Mike Blumenkrantz
> > Zentific: NULL pointer dereferences now 50% off!
> >
probably around the same time that e17 v1.0 is released

-- 
Mike Blumenkrantz
Zentific: NULL pointer dereferences now 50% off!

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel

Re: [E-devel] Changing the E Menu

[The Rasterman]

On Fri, 18 Mar 2011 01:56:30 -0500 Jeff Hoogland  said:

http://trac.enlightenment.org/e/wiki/Release

> When will the info be shared with those of us kept away from cebit?
> 
> ~Jeff
> 
> On Fri, Mar 18, 2011 at 1:55 AM, Mike Blumenkrantz wrote:
> 
> > On Fri, 18 Mar 2011 01:46:43 -0500
> > Jeff Hoogland  wrote:
> >
> > > All this talk about holding up the E17 release - was there a memo sent
> > out
> > > that I missed? Has a targeted release date been set?
> > >
> > > ~Jeff Hoogland
> > >
> > > On Fri, Mar 18, 2011 at 1:22 AM, Carsten Haitzler  > >wrote:
> > >
> > > > On Thu, 17 Mar 2011 11:46:31 -0500 Jeff Hoogland
> > 
> > > > said:
> > > >
> > > > reality is.. it's not going to become some circular menu or pie menu or
> > > > anything else... because it's not needed and i am not going to hold up
> > e17
> > > > release for a "rewrite of the start menu". it stays as-is. maybe we can
> > > > re-org
> > > > some items, but it needs to stay.
> > > >
> > > > > So back to the main e menu... This is a bit of a drastic change, but
> > I
> > > > > really like. Gives a very sleek feeling - a "fan" menu. Some mock ups
> > one
> > > > of
> > > > > my artists did:
> > > > >
> > > > > Static:
> > > > > http://i.imgur.com/VhDxz.png
> > > > >
> > > > > Semi Animate:
> > > > > http://dl.dropbox.com/u/12757360/out%201.gif
> > > > >
> > > > > Anyone else like this?
> > > > > Cheers,
> > > > > ~Jeff Hoogland
> > > > >
> > > > > On Wed, Mar 16, 2011 at 8:19 PM, hannes.janet...@gmail.com <
> > > > > hannes.janet...@googlemail.com> wrote:
> > > > >
> > > > > > On Thu, Mar 17, 2011 at 1:56 AM, Brian 'morlenxus' Miculcy
> > > > > >  wrote:
> > > > > > > On Thu, Mar 17, 2011 at 01:25:15AM +0100,
> > > > hannes.janetzek@gmail.comwrote:
> > > > > > >> On Wed, Mar 16, 2011 at 9:10 PM, Tom Hacohen 
> > wrote:
> > > > > > >> > On Wed, Mar 16, 2011 at 8:56 PM, Cedric BAIL <
> > cedric.b...@free.fr
> > > > >
> > > > > > wrote:
> > > > > > >> >
> > > > > > >> >>  We do have some nice infra that should make it possible to
> > > > include
> > > > > > >> >> gadget directly inside the menu and have some cool stuff like
> > > > that.
> > > > > > >> >> But that require some work and I don't think it should be a
> > > > blocker
> > > > > > >> >> for a release. It could be just and extra module to start and
> > > > later
> > > > > > >> >> moved inside E17 or maybe more inside E18.
> > > > > > >> >>
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > We are talking about reordering stuff, nothing more.
> > > > > > >> >
> > > > > > >>
> > > > > > >> Talking about reordering menus. currently gadget right click
> > shows
> > > > two
> > > > > > items:
> > > > > > >>
> > > > > > >> gadget >
> > > > > > >> shelf>
> > > > > > >>
> > > > > > >> causing one to do the extra step to go the gadget submenu all
> > the
> > > > > > >> time. which is more annoying when one has to move the mouse
> > against
> > > > > > >> the screen edge to reveal the menu. Any objections to fix all
> > gadget
> > > > > > >> right click menus to this layout:
> > > > > > >>
> > > > > > >> gadget settings
> > > > > > >> 
> > > > > > >> -
> > > > > > >> move/resize
> > > > > > >> layout
> > > > > > >> .
> > > > > > >> -
> > > > > > >> shelf>
> > > > > > >>
> > > > > > >>
> > > > > > >> Regards,
> > > > > > >> Hannes
> > > > > > >
> > > > > > > Yes, i think the current gadget menu is well ordered. Let's not
> > > > clutter
> > > > > > it like before.
> > > > > >
> > > > > > ok then what about:
> > > > > >
> > > > > > Settings
> > > > > > [gadget specific actions:]
> > > > > > 'add item'
> > > > > > 'contents'
> > > > > > --
> > > > > > Gadget Ibar   >
> > > > > > Shelf Settings   >
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Hannes
> > > > > >
> > > > > >
> > > > > > Also check the ibar menu, this is more clearer as when putting
> > > > > > everything at the top level. Let's try to really make the window
> > menu
> > > > > > more simpler. For example there is not much sense to have the
> > minimise
> > > > > > action at the top level as it's mostly available via border
> > buttons. I
> > > > > > will send a new window menu tree proposal later today, just need
> > some
> > > > > > sleep now...
> > > > > > >
> > > > > > > Kind regards,
> > > > > > > Brian
> > > > > > >>
> > > > > > >>
> > > > > > >> > --
> > > > > > >> > Tom.
> > > > > > >> >
> > > > > >
> > cebit.
> >
> > --
> > Mike Blumenkrantz
> > Zentific: NULL pointer dereferences now 50% off!
> >
> --
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinf

Re: [E-devel] Mac OS X and library version

[The Rasterman]

On Fri, 18 Mar 2011 07:53:53 +0100 (CET) Vincent Torri 
said:

> 
> 
> On Fri, 18 Mar 2011, Carsten Haitzler (The Rasterman) wrote:
> 
> > On Thu, 17 Mar 2011 10:56:27 -0300 Iván Briano (Sachiel)
> >  said:
> >
> >> 2011/3/17 Mike Blumenkrantz :
> >>> On Thu, 17 Mar 2011 07:28:44 +0100
> >>> s...@tango.flipp.net wrote:
> >>>
>  Hi,
> 
>  Got a complaint from a Mac OS X user that building from trunk fails. The
>  reason is the v_mic number:
> 
>  ld: malformed version number: 2.999
> 
>  After checking I found the reason:
> 
>  -current_version number
>        Specifies the current version number of the library. The current
>  version of the library can
>        be obtained programmatically by the user of the library so it can
>  determine exactly which
>        version of the library it is using.  The format of number is X[.Y
>  [.Z]] where X must be a
>        positive non-zero number less than or equal to 65535, and .Y and .Z
>  are optional and if
>        present must be non-negative numbers less than or equal to 255.  If
>  the version number is
>        not specified, it has a value of 0.  This option is also called
>  -dylib_current_version for
>        compatibility.
> 
>  So on OS X v_mic can't be larger than 255. Should we make this default
>  for all platforms, or just for darwin?
> 
>  S.
> 
> >>> I think just setting it to 99 on all platforms would be sufficient, it's
> >>> unlikely that we'll ever get that high?
> >>>
> >>
> >> Most of the times you are way higher than that.
> >
> > we canty change version as all the .999 versions now installed from trunk
> > will be newer than the .99 that is now newer. so i guess mac-osx is now
> > unsupported until we release 1.0.1 bugfix updates or 1.1 you cant use trunk
> > without modifying the version installed.
> 
> so we revert it, and set it to 99 after the next release ?

yes. revert. osx will just not get support from trunk until then. too bad they
have such limiting version number support. peolpe will have to patch their own
installs in the meantime.

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


--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [PATCH] evas objec line: use EVAS_MEMPOOL_FREE instead of free

[Jiyoun Park]

Dear all


In the Evas_object_line of the evas, the function
“evas_object_line_free” function have a problem.
If the define MPOOL was set(in Evas_private.h), 
evas_object_line use unpaired memory function.

Evas_object_line use EVAS_MEMPOOL_INIT,EVAS_MEMPOOL_ALLOC, and
EVAS_MEMPOOL_PREP, 
but does not use EVAS_MEMPOOL_FREE. 

I changed evas_object_line_free use EVAS_MEMPOOL_FREE instead of free
function.
Please find attached patch file.

And I add my name and info into AUTHOR file.

Thanks,
Jiyoun Park.



evas_object_line.patch
Description: Binary data
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] evas objec line: use EVAS_MEMPOOL_FREE instead of free

[Cedric BAIL]

2011/3/18 Jiyoun Park :
> Dear all
>
> In the Evas_object_line of the evas, the function
> “evas_object_line_free” function have a problem.
> If the define MPOOL was set(in Evas_private.h),
> evas_object_line use unpaired memory function.
>
> Evas_object_line use EVAS_MEMPOOL_INIT,EVAS_MEMPOOL_ALLOC, and
> EVAS_MEMPOOL_PREP,
> but does not use EVAS_MEMPOOL_FREE.
>
> I changed evas_object_line_free use EVAS_MEMPOOL_FREE instead of free
> function.
> Please find attached patch file.
>
> And I add my name and info into AUTHOR file.

Good. In svn and backported.
-- 
Cedric BAIL

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] The problem of the parameter in ecore_imf_context_input_mode_set

[Jihoon Kim]

Hello,

I think there are a problem of parameter in
ecore_imf_context_input_mode_set().

The second parameter of that API can be combined more than an enum value
such ECORE_IMF_INPUT_MODE_HEXA | ECORE_IMF_MODE_TELE.

It is weird. In this situation (HEXA | TELE), Which layout should the
virtual keyboard show?
The concept of combination makes us confused.

If there is no special reason that we should use this API, I'd like to add
the new API.



--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] evas objec line: use EVAS_MEMPOOL_FREE instead of free

[Daniel Juyung Seo]

Good. I added Jiyoun to evas/doc/evas.dox.in as well.
This will be applied to below link later.
http://docs.enlightenment.org/auto/evas/

Thanks.

Daniel Juyung Seo (SeoZ)

On Fri, Mar 18, 2011 at 7:57 PM, Cedric BAIL  wrote:
> 2011/3/18 Jiyoun Park :
>> Dear all
>>
>> In the Evas_object_line of the evas, the function
>> “evas_object_line_free” function have a problem.
>> If the define MPOOL was set(in Evas_private.h),
>> evas_object_line use unpaired memory function.
>>
>> Evas_object_line use EVAS_MEMPOOL_INIT,EVAS_MEMPOOL_ALLOC, and
>> EVAS_MEMPOOL_PREP,
>> but does not use EVAS_MEMPOOL_FREE.
>>
>> I changed evas_object_line_free use EVAS_MEMPOOL_FREE instead of free
>> function.
>> Please find attached patch file.
>>
>> And I add my name and info into AUTHOR file.
>
> Good. In svn and backported.
> --
> Cedric BAIL
>
> --
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [Patch] imlib2 dso fix.

[Daniel Juyung Seo]

Hello,
This is an imlib2 dso fix patch.
Even imlib2 is deprecated, it is still in trunk and is probably used by
someone.
Please review this patch.
Thanks.

Daniel Juyung Seo (SeoZ)


imlib2.diff
Description: Binary data
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] evas objec line: use EVAS_MEMPOOL_FREE instead of free

[Cedric BAIL]

On Fri, Mar 18, 2011 at 1:29 PM, Daniel Juyung Seo  wrote:
> Good. I added Jiyoun to evas/doc/evas.dox.in as well.
> This will be applied to below link later.
> http://docs.enlightenment.org/auto/evas/

Oops, sorry I always forget that. Maybe we could autogenerate this
list from the AUTHORS file ?
-- 
Cedric BAIL

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] evas objec line: use EVAS_MEMPOOL_FREE instead of free

[Daniel Juyung Seo]

Yes, this is not hard.
I was planning to do that. But just matter of time :)

Thanks.
Daniel Juyung Seo (SeoZ)

On Fri, Mar 18, 2011 at 10:15 PM, Cedric BAIL  wrote:
> On Fri, Mar 18, 2011 at 1:29 PM, Daniel Juyung Seo  
> wrote:
>> Good. I added Jiyoun to evas/doc/evas.dox.in as well.
>> This will be applied to below link later.
>> http://docs.enlightenment.org/auto/evas/
>
> Oops, sorry I always forget that. Maybe we could autogenerate this
> list from the AUTHORS file ?
> --
> Cedric BAIL
>

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Proposal on providing internationalization support for EDC TEXT

[Rajeev Ranjan]

Hi,

 

TEXT/TEXTBLOCK supports setting a string directly in edc.  So how to 
internationalize this string?

 

We thought of few approaches. I am listing down them here.

 

Approach  1:

   Widgets/Applications based on elementary can use API 
edje_object_part_text_set(Evas_Object*, const char*, const 
char* ); to set the text part by making use of I18N support of 
elementary(using gettext).

Pros/Cons: This again depends in C Code, Theme extendibility is lost.

 

Approach 2: 

   Having separate Attibutes to TEXT/TEXTBLOCK part for each of the languages 
being supported.

e.g. text.text_enGB:"http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Proposal on providing internationalization support for EDC TEXT

[Cedric BAIL]

Hi,

On Fri, Mar 18, 2011 at 3:27 PM, Rajeev Ranjan  wrote:
> TEXT/TEXTBLOCK supports setting a string directly in edc.  So how to 
> internationalize this string?

I will first point you to my old proposal that I didn't get time nor
urgency to do :
http://lists.enlightenment.fr/enlightenment-devel/2010/07/33748.html .
But I did have some more idea since then.

> We thought of few approaches. I am listing down them here.

> Approach  1:
>
>   Widgets/Applications based on elementary can use API 
> edje_object_part_text_set(Evas_Object*, const char*, const 
> char* ); to set the text part by making use of I18N support of 
> elementary(using gettext).
>
> Pros/Cons: This again depends in C Code, Theme extendibility is lost.

Yep, so a no go.

> Approach 2:
>
>   Having separate Attibutes to TEXT/TEXTBLOCK part for each of the languages 
> being supported.
>
> e.g. text.text_enGB:"
>  text_ko:"
> Pros/Cons:  No reusability and makes the block definition bulky and complex.

Would also be incompatible with all translation tool.

> Approach 3:  Edje lib can do the translation with gettext package support.   
> TEXT/TEXTBLOCK can have additional  attribute pkg_name  to locate the gettext 
> package.
>
> e.g. text.pkg_name: "edje";// package name in this example is elementary.
>
>  text.text: "string";

In fact, Edje file format already provide the possibility to do so.
Look inside edje/src/lib/edje_util.c in both functions edje_string_get
and edje_string_id_get. This is where this should be done imho. And
edje_cc parser should be extended by beeing able to handle _(String)
and automatically register this string in the internationalization
support.

> and PO files can be packed as part of EDJ.
>
> This approach will have backward compatibility with the existing edc files.

The problem with that solution is that it will not be included inside
the edje file and will break the nice one file to distribut and
install feature. It will also not take advantage of our full knowledge
of the string we need to translate at compile time. That means we do
not need to use a hash at runtime, but only an index in an array.

Now what is my current idea. It's easy : implement gettext like
interface in eet. Reason, not only edje will benefit from this
capability. For example you could add translation support to eyelight
easily if it was done at eet level.

So compared to my previous proposition, we will need to provide this
list of tools for eet :
- eet_xgettext will generate the .pot file from the Eet mapping information.
- eet_msgfmt will insert a .po inside an existing Eet section
("eet/localization/en_us") as an array of string (not translated
string will be NULL). It should show the percent of translated string
and do some check if the translation already exist (like overridding
existing content and stuff like that).
- eet_msgunfmt will extract a .po from an Eet file.
- eet_locale will display statistic of all translation of an Eet file.
- eet_locale_default will alias a translation to an Eet section (just
linking to "eet/localization/default")

Doing it with eet give us a lot of advantage, we could decide to
compress per language (so depending on what we need we can insert the
string in the eet_dictionnary or keep them compressed in an eet_data)
and accessing a string will be just a direct hit in an array (no need
to walk a hash). Of course it also preserve the main advantage,
delivering a compleltly self contained theme.

As I see it edje_cc parser (or eyelight parser) will do :
- request the internationalization context from eet (eet will create
it, if the file doesn't already have it)
- request an id that match a string (in both case, sting are static
stuff, so no need to handle plural form at this level), eet will also
add that string to the default locale array to.
- store the id in there own structure.
- close the internationalization context.

In edje_string_get, we will do something like that :
- if no locale open, request the right one from eet.
- request the string that match an id (eet will open the default map
if there is no translation and return the original string).
- hold a pointer to that string as it will not change after that.

When we do change the locale assigned to an edje object, we will just
need to wipeout all strings and let edje do the request when needed.

Handling plural is in my opinion not that much complex, but would be
just needed if we do plan to provide translation of string coming from
a lua or embryo script. I personnally think we should do it, so if I
have time to do it, I will do just that.

That make a fourth proposition, you can forget mine from July.
-- 
Cedric BAIL

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing

Re: [E-devel] Changing the E Menu

[alex kovacic]

+1
On 18/03/2011 5:22 PM, Carsten Haitzler wrote:
> On Thu, 17 Mar 2011 11:46:31 -0500 Jeff Hoogland  
> said:
>
> reality is.. it's not going to become some circular menu or pie menu or
> anything else... because it's not needed and i am not going to hold up e17
> release for a "rewrite of the start menu". it stays as-is. maybe we can re-org
> some items, but it needs to stay.
>
>> So back to the main e menu... This is a bit of a drastic change, but I
>> really like. Gives a very sleek feeling - a "fan" menu. Some mock ups one of
>> my artists did:
>>
>> Static:
>> http://i.imgur.com/VhDxz.png
>>
>> Semi Animate:
>> http://dl.dropbox.com/u/12757360/out%201.gif
>>
>> Anyone else like this?
>> Cheers,
>> ~Jeff Hoogland
>>
>> On Wed, Mar 16, 2011 at 8:19 PM, hannes.janet...@gmail.com<
>> hannes.janet...@googlemail.com>  wrote:
>>
>>> On Thu, Mar 17, 2011 at 1:56 AM, Brian 'morlenxus' Miculcy
>>>   wrote:
 On Thu, Mar 17, 2011 at 01:25:15AM +0100, hannes.janetzek@gmail.comwrote:
> On Wed, Mar 16, 2011 at 9:10 PM, Tom Hacohen  wrote:
>> On Wed, Mar 16, 2011 at 8:56 PM, Cedric BAIL
>>> wrote:
>>>   We do have some nice infra that should make it possible to include
>>> gadget directly inside the menu and have some cool stuff like that.
>>> But that require some work and I don't think it should be a blocker
>>> for a release. It could be just and extra module to start and later
>>> moved inside E17 or maybe more inside E18.
>>>
>>
>> We are talking about reordering stuff, nothing more.
>>
> Talking about reordering menus. currently gadget right click shows two
>>> items:
> gadget>
> shelf>
>
> causing one to do the extra step to go the gadget submenu all the
> time. which is more annoying when one has to move the mouse against
> the screen edge to reveal the menu. Any objections to fix all gadget
> right click menus to this layout:
>
> gadget settings
> 
> -
> move/resize
> layout
> .
> -
> shelf>
>
>
> Regards,
> Hannes
 Yes, i think the current gadget menu is well ordered. Let's not clutter
>>> it like before.
>>>
>>> ok then what about:
>>>
>>> Settings
>>> [gadget specific actions:]
>>> 'add item'
>>> 'contents'
>>> --
>>> Gadget Ibar>
>>> Shelf Settings>
>>>
>>>
>>> Regards,
>>> Hannes
>>>
>>>
>>> Also check the ibar menu, this is more clearer as when putting
>>> everything at the top level. Let's try to really make the window menu
>>> more simpler. For example there is not much sense to have the minimise
>>> action at the top level as it's mostly available via border buttons. I
>>> will send a new window menu tree proposal later today, just need some
>>> sleep now...
 Kind regards,
 Brian
>
>> --
>> Tom.
>>
>>> --
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>
>>> --
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>>
>>> --
>>> Colocation vs. Managed Hosting
>>> A question and answer guide to determining the best fit
>>> for your organization - today and in the future.
>>> http://p.sf.net/sfu/internap-sfd2d
>>> ___
>>> enlightenment-devel mailing list
>>> enlightenment-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>>
>> --
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>


--
Colocation vs. Managed Hosting
A question and answer guide to determining the b

[E-devel] enlightenment_remote methods

[orcun avsar]

Hi,
We've prepared an Enlightenment version Gnu/Pardus of distro. Pardus has a
manager named Kaptan which runs at first startup of the system and make some
customizations(wallpapers, themes, mouse and keyboard configurations) and
applies them. When we have edje files ready to apply to system we couldn't
found a way of it. Pentoo uses an old version of enlightenment_remote script
which i thought it has dbus calls these are now obselete! What's the
replacement solution for this or can you direct me to source code of GUI
application that sets wallpapers, icons and themes for examination. Thank
you..
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [Patch] Eeze - Implement eeze_udev_syspath_get_sysname()

[Clément Battin]

Hi there.

Here's eeze_udev_syspath_get_sysname() for Eeze.

Regards,

Clement Battin.



sysname.diff
Description: Binary data
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Proposal on providing internationalization support for EDC TEXT

[Rui Miguel Silva Seabra]

Em 18-03-2011 15:12, Cedric BAIL escreveu:
> In fact, Edje file format already provide the possibility to do so.
> Look inside edje/src/lib/edje_util.c in both functions edje_string_get
> and edje_string_id_get. This is where this should be done imho. And
> edje_cc parser should be extended by beeing able to handle _(String)
> and automatically register this string in the internationalization
> support.

At least with gettext, IIRC, you can't do printf(_(var)). You always 
have to do it with a fixed string, eg, printf(_("Warning: %s\n"), msg)

Rui

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] strange returned value of epp

[Vincent Torri]

hey

question for discomfitor:

in epp/Makefile.am, I see:

-DFATAL_EXIT_CODE=1 \
-DSUCCESS_EXIT_CODE=1 \

is it normal ?

Vincent

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: discomfitor IN trunk/eeze: . src/lib

[Gustavo Sverzut Barbieri]

On Fri, Mar 18, 2011 at 5:10 PM, Enlightenment SVN
 wrote:
> Log:
> +eeze_udev_syspath_get_devname, thanks to Clement Battin

damn naming scheme... it should be devname_get not the other way
around... bad Discomfitor!


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: discomfitor IN trunk/eeze: . src/lib

[Mike Blumenkrantz]

On Fri, 18 Mar 2011 18:08:53 +
Gustavo Sverzut Barbieri  wrote:

> On Fri, Mar 18, 2011 at 5:10 PM, Enlightenment SVN
>  wrote:
> > Log:
> > +eeze_udev_syspath_get_devname, thanks to Clement Battin
> 
> damn naming scheme... it should be devname_get not the other way
> around... bad Discomfitor!
> 
> 
no, eeze_udev uses a different naming scheme.

-- 
Mike Blumenkrantz
Zentific: NULL pointer dereferences now 50% off!

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] strange returned value of epp

[Mike Blumenkrantz]

On Fri, 18 Mar 2011 19:08:12 +0100 (CET)
Vincent Torri  wrote:

> 
> hey
> 
> question for discomfitor:
> 
> in epp/Makefile.am, I see:
> 
> -DFATAL_EXIT_CODE=1 \
> -DSUCCESS_EXIT_CODE=1 \
> 
> is it normal ?
> 
> Vincent
> 
I copied it out of e16. Probably should be 0 on success exit though.

-- 
Mike Blumenkrantz
Zentific: NULL pointer dereferences now 50% off!

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: discomfitor IN trunk/eeze: . src/lib

[Gustavo Sverzut Barbieri]

On Fri, Mar 18, 2011 at 6:18 PM, Mike Blumenkrantz  wrote:
> On Fri, 18 Mar 2011 18:08:53 +
> Gustavo Sverzut Barbieri  wrote:
>
>> On Fri, Mar 18, 2011 at 5:10 PM, Enlightenment SVN
>>  wrote:
>> > Log:
>> > +eeze_udev_syspath_get_devname, thanks to Clement Battin
>>
>> damn naming scheme... it should be devname_get not the other way
>> around... bad Discomfitor!
>>
>>
> no, eeze_udev uses a different naming scheme.

I've noticed, bummer! But why so? It makes coding a less interesting
thing as you make more mistakes :-(


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: discomfitor IN trunk/eeze: . src/lib

[Mike Blumenkrantz]

On Fri, 18 Mar 2011 18:20:12 +
Gustavo Sverzut Barbieri  wrote:

> On Fri, Mar 18, 2011 at 6:18 PM, Mike Blumenkrantz  wrote:
> > On Fri, 18 Mar 2011 18:08:53 +
> > Gustavo Sverzut Barbieri  wrote:
> >
> >> On Fri, Mar 18, 2011 at 5:10 PM, Enlightenment SVN
> >>  wrote:
> >> > Log:
> >> > +eeze_udev_syspath_get_devname, thanks to Clement Battin
> >>
> >> damn naming scheme... it should be devname_get not the other way
> >> around... bad Discomfitor!
> >>
> >>
> > no, eeze_udev uses a different naming scheme.
> 
> I've noticed, bummer! But why so? It makes coding a less interesting
> thing as you make more mistakes :-(
> 
> 
I changed it for 2 reasons:
1) Reminder that there will never be eeze_udev_*set functions
2) Reminder that the results are stringshared (other eeze functions do NOT
return stringshared values)

-- 
Mike Blumenkrantz
Zentific: NULL pointer dereferences now 50% off!

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Changing the E Menu

[Brian 'morlenxus' Miculcy]

Here is a mockup for a better window menu:
http://omicron.homeip.net/files/new_windowmenu.html

I think this makes the window menu really slim and useable.

Kind regards,
Brian 'morlenxus' Miculcy

On Thu, Mar 17, 2011 at 01:56:20AM +0100, Brian 'morlenxus' Miculcy wrote:
> On Thu, Mar 17, 2011 at 01:25:15AM +0100, hannes.janet...@gmail.com wrote:
> > On Wed, Mar 16, 2011 at 9:10 PM, Tom Hacohen  wrote:
> > > On Wed, Mar 16, 2011 at 8:56 PM, Cedric BAIL  wrote:
> > >
> > >>  We do have some nice infra that should make it possible to include
> > >> gadget directly inside the menu and have some cool stuff like that.
> > >> But that require some work and I don't think it should be a blocker
> > >> for a release. It could be just and extra module to start and later
> > >> moved inside E17 or maybe more inside E18.
> > >>
> > >
> > >
> > > We are talking about reordering stuff, nothing more.
> > >
> > 
> > Talking about reordering menus. currently gadget right click shows two 
> > items:
> > 
> > gadget >
> > shelf>
> > 
> > causing one to do the extra step to go the gadget submenu all the
> > time. which is more annoying when one has to move the mouse against
> > the screen edge to reveal the menu. Any objections to fix all gadget
> > right click menus to this layout:
> > 
> > gadget settings
> > 
> > -
> > move/resize
> > layout
> > .
> > -
> > shelf>
> > 
> > 
> > Regards,
> > Hannes
> 
> Yes, i think the current gadget menu is well ordered. Let's not clutter it 
> like before. Also check the ibar menu, this is more clearer as when putting 
> everything at the top level. Let's try to really make the window menu more 
> simpler. For example there is not much sense to have the minimise action at 
> the top level as it's mostly available via border buttons. I will send a new 
> window menu tree proposal later today, just need some sleep now...
> 
> Kind regards,
> Brian
> > 
> > 
> > > --
> > > Tom.
> > > --
> > > Colocation vs. Managed Hosting
> > > A question and answer guide to determining the best fit
> > > for your organization - today and in the future.
> > > http://p.sf.net/sfu/internap-sfd2d
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >
> > 
> > --
> > Colocation vs. Managed Hosting
> > A question and answer guide to determining the best fit
> > for your organization - today and in the future.
> > http://p.sf.net/sfu/internap-sfd2d
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 
> --
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Changing the E Menu

[Mike Blumenkrantz]

On Fri, 18 Mar 2011 19:36:49 +0100
Brian 'morlenxus' Miculcy  wrote:

> Here is a mockup for a better window menu:
> http://omicron.homeip.net/files/new_windowmenu.html
> 
> I think this makes the window menu really slim and useable.
> 
> Kind regards,
> Brian 'morlenxus' Miculcy
> 
> On Thu, Mar 17, 2011 at 01:56:20AM +0100, Brian 'morlenxus' Miculcy wrote:
> > On Thu, Mar 17, 2011 at 01:25:15AM +0100, hannes.janet...@gmail.com wrote:
> > > On Wed, Mar 16, 2011 at 9:10 PM, Tom Hacohen  wrote:
> > > > On Wed, Mar 16, 2011 at 8:56 PM, Cedric BAIL 
> > > > wrote:
> > > >
> > > >>  We do have some nice infra that should make it possible to include
> > > >> gadget directly inside the menu and have some cool stuff like that.
> > > >> But that require some work and I don't think it should be a blocker
> > > >> for a release. It could be just and extra module to start and later
> > > >> moved inside E17 or maybe more inside E18.
> > > >>
> > > >
> > > >
> > > > We are talking about reordering stuff, nothing more.
> > > >
> > > 
> > > Talking about reordering menus. currently gadget right click shows two
> > > items:
> > > 
> > > gadget >
> > > shelf>
> > > 
> > > causing one to do the extra step to go the gadget submenu all the
> > > time. which is more annoying when one has to move the mouse against
> > > the screen edge to reveal the menu. Any objections to fix all gadget
> > > right click menus to this layout:
> > > 
> > > gadget settings
> > > 
> > > -
> > > move/resize
> > > layout
> > > .
> > > -
> > > shelf>
> > > 
> > > 
> > > Regards,
> > > Hannes
> > 
> > Yes, i think the current gadget menu is well ordered. Let's not clutter it
> > like before. Also check the ibar menu, this is more clearer as when putting
> > everything at the top level. Let's try to really make the window menu more
> > simpler. For example there is not much sense to have the minimise action at
> > the top level as it's mostly available via border buttons. I will send a
> > new window menu tree proposal later today, just need some sleep now...
> > 
> > Kind regards,
> > Brian
> > > 
> > > 
> > > > --
> > > > Tom.
Definitely a step in the right direction.

-- 
Mike Blumenkrantz
Zentific: NULL pointer dereferences now 50% off!

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] strange returned value of epp

[Daniel McLellan]

that Makefile.am edit solved the issue. thanks.

On Fri, Mar 18, 2011 at 1:46 PM, Daniel McLellan
wrote:

> [@][~/e/trunk/elementary/data/themes]edje_cc default.edc default.edj
>  ** have epp : yes
>  ** epp return value : 0
>:)
>
>
> On Fri, Mar 18, 2011 at 1:19 PM, Mike Blumenkrantz wrote:
>
>> On Fri, 18 Mar 2011 19:08:12 +0100 (CET)
>> Vincent Torri  wrote:
>>
>> >
>> > hey
>> >
>> > question for discomfitor:
>> >
>> > in epp/Makefile.am, I see:
>> >
>> > -DFATAL_EXIT_CODE=1 \
>> > -DSUCCESS_EXIT_CODE=1 \
>> >
>> > is it normal ?
>> >
>> > Vincent
>> >
>> I copied it out of e16. Probably should be 0 on success exit though.
>>
>> --
>> Mike Blumenkrantz
>> Zentific: NULL pointer dereferences now 50% off!
>>
>>
>> --
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>
>
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: discomfitor IN trunk/efreet: . src/bin src/lib

[Vincent Torri]

On Fri, 18 Mar 2011, Enlightenment SVN wrote:

> Log:
> use eina_log more effectively: replace all printfs with appropriate log 
> functions and use EINA_LOG_ERR instead of ERR when log dom fails to init

ERR("Efreet: ");   < don't put 'Efreet' in those macros, as 
eina_log will take care of that

Vincent

>
>
> Author:   discomfitor
> Date: 2011-03-18 12:47:57 -0700 (Fri, 18 Mar 2011)
> New Revision: 57858
> Trac: http://trac.enlightenment.org/e/changeset/57858
>
> Modified:
>  trunk/efreet/ChangeLog trunk/efreet/src/bin/efreet_icon_cache_create.c 
> trunk/efreet/src/lib/efreet_base.c trunk/efreet/src/lib/efreet_cache.c 
> trunk/efreet/src/lib/efreet_desktop.c trunk/efreet/src/lib/efreet_ini.c 
> trunk/efreet/src/lib/efreet_menu.c trunk/efreet/src/lib/efreet_mime.c 
> trunk/efreet/src/lib/efreet_trash.c trunk/efreet/src/lib/efreet_utils.c 
> trunk/efreet/src/lib/efreet_xml.c
>
> Modified: trunk/efreet/ChangeLog
> ===
> --- trunk/efreet/ChangeLog2011-03-18 19:46:52 UTC (rev 57857)
> +++ trunk/efreet/ChangeLog2011-03-18 19:47:57 UTC (rev 57858)
> @@ -77,3 +77,7 @@
>   * Delay cache recreation with a timer
>   * Move desktop cache to efreet_cache.c, and cache all requests which
> hit the eet cache
> +
> +2011-03-18  Mike Blumenkrantz
> +
> +* Use eina_log more effectively
>
> Modified: trunk/efreet/src/bin/efreet_icon_cache_create.c
> ===
> --- trunk/efreet/src/bin/efreet_icon_cache_create.c   2011-03-18 19:46:52 UTC 
> (rev 57857)
> +++ trunk/efreet/src/bin/efreet_icon_cache_create.c   2011-03-18 19:47:57 UTC 
> (rev 57858)
> @@ -16,7 +16,8 @@
> #include 
> #include 
>
> -#define EFREET_MODULE_LOG_DOM /* no logging in this file */
> +#define EFREET_MODULE_LOG_DOM _efreet_icon_cache_log_dom
> +static int _efreet_icon_cache_log_dom = -1;
>
> #include "Efreet.h"
> #include "efreet_private.h"
> @@ -34,7 +35,6 @@
> static Eina_Array *extra_dirs = NULL;
> static Eina_Array *strs = NULL;
> static Eina_Hash *icon_themes = NULL;
> -static int verbose = 0;
>
> static Eina_Bool
> cache_directory_find(Eina_Hash *dirs, const char *dir)
> @@ -305,8 +305,8 @@
> Efreet_Icon_Theme *inherit;
>
> inherit = eina_hash_find(icon_themes, name);
> -if (!inherit && verbose)
> -fprintf(stderr, "Theme `%s` not found for `%s`.\n",
> +if (!inherit)
> +INF("Theme `%s` not found for `%s`.",
> name, theme->name.internal);
> if (!cache_scan(inherit, themes, icons, dirs, changed)) return 
> EINA_FALSE;
> }
> @@ -336,8 +336,8 @@
> Efreet_Cache_Icon_Theme *inherit;
>
> inherit = eina_hash_find(icon_themes, name);
> -if (!inherit && verbose)
> -fprintf(stderr, "Theme `%s` not found for `%s`.\n",
> +if (!inherit)
> +INF("Theme `%s` not found for `%s`.",
> name, theme->theme.name.internal);
> if (check_changed(inherit)) return EINA_TRUE;
> }
> @@ -627,7 +627,7 @@
> fl.l_whence = SEEK_SET;
> if (fcntl(lockfd, F_SETLK, &fl) < 0)
> {
> -if (verbose) printf("LOCKED! You may want to delete %s if this 
> persists\n", file);
> +WRN("LOCKED! You may want to delete %s if this persists", file);
> close(lockfd);
> return -1;
> }
> @@ -680,13 +680,23 @@
>
> /* init external subsystems */
> if (!eina_init()) return -1;
> +_efreet_icon_cache_log_dom = eina_log_domain_register
> +  ("efreet_icon_cache", EFREET_DEFAULT_LOG_COLOR);
> +if (_efreet_icon_cache_log_dom < 0)
> +{
> +EINA_LOG_ERR("Efreet: Could not create a log domain for 
> efreet_icon_cache.");
> +return -1;
> +}
>
> +eina_log_domain_level_set("efreet_icon_cache", EINA_LOG_LEVEL_ERR);
> +
> exts = eina_array_new(10);
> extra_dirs = eina_array_new(10);
>
> for (i = 1; i < argc; i++)
> {
> -if  (!strcmp(argv[i], "-v")) verbose = 1;
> +if (!strcmp(argv[i], "-v"))
> +  eina_log_domain_level_set("efreet_icon_cache", EINA_LOG_LEVEL_DBG);
> else if ((!strcmp(argv[i], "-h")) ||
>  (!strcmp(argv[i], "-help")) ||
>  (!strcmp(argv[i], "--h")) ||
> @@ -711,7 +721,7 @@
> }
> if (exts->count == 0)
> {
> -printf("Error: Need to pass extensions to icon cache create 
> process\n");
> +ERR("Error: Need to pass extensions to icon cache create process");
> return -1;
> }
>
> @@ -743,6 +753,7 @@
>
> icon_themes = 
> eina_hash_string_superfast_new(EINA_FREE_CB(icon_theme_free));
>
> +INF("opening theme cache");
> /* open theme file */
> theme_ef = eet_open(efreet_icon_theme_cache_file(), 
> EET_FILE_MODE_READ_WRITE);
> if (!theme_ef) goto on_error_efreet;

[E-devel] GSoC 2011: sitting this one out....

[Ravenlock]

All,

I am quite disappointed to report that we have not been selected for
Google Summer of Code this year.  Google is only able to accept a
certain number of mentoring organizations each year and they always
receive many more applications than they can accommodate.

There is an IRC meeting scheduled with Google administrators on March
22nd at which time the rejected organizations will have an opportunity
to learn why it is they did not make the cut.  I will be sure to attend
the meeting.

We have had successful GSoC years in the past and we look forward to
applying again in the future in order to participate again.

-- 
Regards,
Ravenlock




signature.asc
Description: OpenPGP digital signature
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: discomfitor IN trunk/eina: . src/lib

[Gustavo Sverzut Barbieri]

On Fri, Mar 18, 2011 at 10:02 PM, Enlightenment SVN
 wrote:
> Log:
> use stringshare in eina_error
>  the only restriction here is that eina_error_msg_register cannot be used 
> internally by eina prior to stringshare init, but since this does not happen 
> currently there is no problem :)

I guess this will cause dependency problems as eina_error is not
supposed to depend on things like stringshare that depends on mempool.


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] packaging

[Mike Blumenkrantz]

Hi,

If you currently build/maintain packages for a distro, or know where they are
located, please update this site with more correct information:

http://trac.enlightenment.org/e/wiki/Operating_Systems

-- 
Mike Blumenkrantz
Zentific: NULL pointer dereferences now 50% off!

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Proposed new EFL Manual (and some wiki updates)

[The Rasterman]

On Tue, 22 Feb 2011 20:13:19 +0100 Yassin  said:

> Hello,
> what about this manual,please?

nothng much has happened. basically it's hard to do a good manual as long as
all the documentation is in the .c files of libs - ie we have to trawl all
sources to get doxygen info out etc. so we can cross-link libs and api calls. a
first pass is moving documentation to public headers at least. then this is
more doable. :)

> On 17/12/2010 18:11, Kim Lester wrote:
> > All,
> >
> > A few notes and two requests (marked *** )
> >
> > 1)
> > Attached is a 0th order draft of a proposed EFL manual to replace all the
> > other "manuals". Or more accurately here is a half written manual to
> > replace the other half written manuals :-)
> >
> > I've cannibalised all the other sources of info that I could find. Once
> > complete and if everyone is happy I suggest the old docs be moved into an
> > ARCHIVE directory (or similar) so they are not accidentally used to provide
> > incorrect info (not that I'm claiming this manual is 100% accurate yet)
> >
> > I have deliberately take some additional info from the doxygen "main page".
> > I don't see doxygen as a suitable "user guide documentation tool" so if
> > there is overview stuff in doxygen IMHO it is better in a proper document
> > and leave doxygen for source code docs and maybe the odd code example.
> >
> > *** I would appreciate feedback on this document.
> >
> > Incidentally I wrote this in OO simply because writing either doxygen or
> > xml is not a good way to evolve a large complex document. I've written
> > large docs in TeX with vi before and whilst it is good for producing
> > consistent output it sucks from the point of view of massive cut/pastes and
> > "creative flow". Eventually this doc _could_ be converted to xml or tex or
> > something but not just now.
> >
> >
> > 2)
> > My suggestion is we create 3 sources of reference documentation (excluding
> > the "casual" wiki for ad-hoc info)
> >
> > 1) The EFL Manual
> > 2) The Edje User Guide (not yet written)
> > 3) The API source.
> >
> >
> > 3)
> > IMHO there are far too many sources and types of info for E at the moment
> > and too many enlightenment subdomains (confusing to me anyway). Info sources
> > 1) web site
> > 2) wiki
> > 3) misc docs in SVN (trunk/DOCS)
> > 4) doxygenated source (auto)
> > 5) doxygentated source (out of date - late 2009)
> >
> > I've stated cleaning up the wiki (done about 20 pages) - see RecentChanges
> > page for last week. I have a list of pages I think should be deleted but
> > I'm not game to do that yet. I think the website (not wiki) needs a bit of
> > tweaking too.
> >
> > ***  I would appreciate some feedback on the wiki changes before I
> > contemplate doing any more work.
> >
> >
> >
> >
> >
> > 4) Passing comment. IMHO the guides for building EFL are poor enough that
> > it would put a lot of people off... More work needs to be done in this area
> > IMHO if you want uptake...
> >
> > it should be as simple as:
> > download source
> > optionally downloads non EFL source deps for  you (as a convenience)
> > make
> >
> > run EFL demos 
> >
> > Other projects manage this
> >
> >
> > cheers
> > Kim
> >
> >
> > --
> > Lotusphere 2011
> > Register now for Lotusphere 2011 and learn how
> > to connect the dots, take your collaborative environment
> > to the next level, and enter the era of Social Business.
> > http://p.sf.net/sfu/lotusphere-d2d
> >
> >
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 
> --
> Free Software Download: Index, Search & Analyze Logs and other IT data in 
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business 
> insights. http://p.sf.net/sfu/splunk-dev2dev 
> ___
> 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


--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] more evas implicits

[The Rasterman]

On Thu, 10 Mar 2011 11:02:56 -0500 Mike Blumenkrantz  said:

> On Thu, 10 Mar 2011 19:22:48 +0900
> Carsten Haitzler (The Rasterman)  wrote:
> 
> > On Mon, 7 Mar 2011 00:34:11 -0500 Mike Blumenkrantz 
> > said:
> > 
> > how do you get these? i don't with -W -Wall -Wextra ... and it always
> > complains of implicit decl's.
> > 
> > > evas_font_draw.c: In function 'evas_common_font_int_cache_glyph_get':
> > > evas_font_draw.c:205: warning: implicit declaration of function
> > > 'evas_common_font_int_promote' evas_font_draw.c:218: warning: implicit
> > > declaration of function 'evas_common_font_int_reload'
> > > evas_font_draw.c:269: warning: implicit declaration of function
> > > 'evas_common_font_int_use_increase' evas_font_draw.c: In function
> > > 'evas_common_font_draw_internal': evas_font_draw.c:689: warning: implicit
> > > declaration of function 'evas_common_font_int_use_trim' CC
> > > evas_image_load.lo CC evas_font_query.lo evas_font_load.c: In function
> > > 'evas_common_font_memory_load': evas_font_load.c:467: warning: implicit
> > > declaration of function 'evas_common_font_int_promote' evas_font_load.c:
> > > At top level: evas_font_load.c:773: warning: conflicting types for
> > > 'evas_common_font_int_promote' evas_font_load.c:467: note: previous
> > > implicit declaration of 'evas_common_font_int_promote' was here
> > > evas_font_load.c: In function 'evas_common_font_int_use_trim':
> > > evas_font_load.c:803: warning: implicit declaration of function
> > > 'evas_common_font_int_unload' evas_font_load.c: At top level:
> > > evas_font_load.c:810: warning: conflicting types for
> > > 'evas_common_font_int_unload' evas_font_load.c:803: note: previous
> > > implicit declaration of 'evas_common_font_int_unload' was here CC
> > > evas_image_save.lo CC evas_image_main.lo CC evas_image_data.lo
> > > evas_font_main.c: In function 'evas_common_font_ascent_get':
> > > evas_font_main.c:90: warning: implicit declaration of function
> > > 'evas_common_font_int_reload' evas_font_query.c: In function
> > > 'evas_common_font_query_kerning': evas_font_query.c:31: warning: implicit
> > > declaration of function 'evas_common_font_int_reload' CC
> > > evas_image_scalecache.lo CC evas_line_main.lo
> > >   CC evas_polygon_main.lo
> > >   CC evas_rectangle_main.lo
> > >   CC evas_scale_main.lo
> > >   CC evas_scale_sample.lo
> > >   CC evas_scale_smooth.lo
> > >   CC evas_scale_span.lo
> > >   CC evas_tiler.lo
> > >   CC evas_regionbuf.lo
> > >   CC evas_pipe.lo
> > >   CC evas_bidi_utils.lo
> > >   CC evas_language_utils.lo
> > >   CC evas_text_utils.lo
> > >   CC evas_font_ot.lo
> > > evas_pipe.c: In function 'evas_common_frameq_schedule_flush_time':
> > > evas_pipe.c:685: warning: implicit declaration of function 'usleep'
> > >   CC evas_map_image.lo
> > > evas_text_utils.c: In function 'evas_common_text_props_content_create':
> > > evas_text_utils.c:193: warning: implicit declaration of function
> > > 'evas_common_font_int_reload'
> > > 
> > > 
> > > -- 
> > > Mike Blumenkrantz
> > > Zentific: NULL pointer dereferences now 50% off!
> > > 
> > > --
> > > What You Don't Know About Data Connectivity CAN Hurt You
> > > This paper provides an overview of data connectivity, details
> > > its effect on application quality, and explores various alternative
> > > solutions. http://p.sf.net/sfu/progress-d2d
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > 
> > 
> > 
> ./configure --disable-cpu-altivec
> --disable-fribidi --disable-directfb --disable-fb
> --enable-fontconfig --disable-gl-flavor-gles --disable-gles-variety-sgx
> --enable-image-loader-gif --enable-image-loader-jpeg --enable-font-loader-eet
> --enable-image-loader-eet --enable-cpu-mmx --enable-image-loader-png
> --disable-software-sdl --enable-cpu-sse --enable-image-loader-svg=static
> --enable-image-loader-tiff=static --enable-pthreads --enable-async-events
> --enable-async-preload --enable-async-render --enable-software-xlib=static
> --enable-xrender-x11=static --enable-software-16-x11=static
> --enable-image-loader-xpm=static --enable-evas-magic-debug
> --enable-static-software-generic --enable-buffer --enable-cpu-c
> --enable-scale-sample --enable-scale-smooth

fixed now.


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


--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-dev

Re: [E-devel] imlib2 caching can fail

[The Rasterman]

On Thu, 17 Mar 2011 11:51:33 +0100 "Jesper Saxtorph"
 said:

the problem is - you are BOTH right and BOTH things break something.
suggestion. use things OTHEr than modified timestamp for comparisons. ie
timestamp must EXACTLY match for caching (== not >=), ANd size, and mode, and
uid and gid, inode... the filesystem may also support (on linux) nanosecond
resolution: st_mtimensec (see bits/stat.h). thats the only kind of solution
that will make everyone happy. still not 100% perfect as size may be the same
and inode re-cycled, and other things the same (als the timestamp discussion)
BUT if the fs supports nanosecond res timestamps... you are golden... well
unless the file was written within the same nanosecond :)

> I understand your thoughts, however I your suggestion will not work. I
> will try to explain it clearer. Bear with me, if it gets a little long
> and I repeat what is written earlier, but I am not sure what part you
> are missing.
> 
> In an ideal world where timestamps has infinite precision and they
> represents the actual real time the files has been changed (never future
> timestamps). If this was the case the original code would work fine.
> 
> In the real world 3 things can happen to break the setup.
> 1) People can force incorrect timestamps.
> 2) By error files can be marked in the future. If this happens we risk
> that the file will be changed again at the exact time of the timestamp,
> which means 2 writes with the same timestamp.
> 3) The file can be written more than one time with the same timestamp
> because of the timestamp resolution.
> 
> Case 1), we should not really care about, as people break the system on
> purpose.
> 
> For both case 2) and 3) the problem happen in the following situation:
> a) Imlib reads the file and register the timestamp of the file (for
> simplification I consider this atomic in this example). The file content
> is cached.
> b) The file is changed, but the timestamp is still the same. This can
> happen according to case 2) and 3) above.
> c) Imlib need the file data again and want
> (imlib_image_set_changes_on_disk) to decide if the cached data is valid.
> It checks the timestamp to validate this. However, as the timestamp has
> not changed, the data are deemed valid, while in reality they are not.
> 
> Now back to your suggestion.
> What you do is the following: On first load you cache the data. On a
> later load you try test if the files current timestamp is right now.
> 
> So lets take an example of why can fail according to case 3):
> I) A file is written at time 17.
> II) The file is read and cached by imlib at time 17.
> III) The file is changed again after the imlib read but still at time
> 17.
> IV) At time 20 imlib need the data again. It try to validate the cache.
> However, since the cache timestamp is still equal to the file timestamp
> and not equal to the current time (20), imlib will validate the cache,
> which is wrong.
> 
> You can make a similar scenario for case 2)
> 
> I hope this makes it more clear.
> 
> -Jesper
> 
> --
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> ___
> 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


--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Patch] Display more than 3 items

[cnook]

Dear All,

Hi~

Thanks for your response.

I have tried to use "data.item" and edje_object_data_get() API. It works
fine. :)

But I met a problem. When I use a new style for elm_diskselector,
edje_object_data_get() cannot retrieve "data.item" of new style.

Only original (default) "data.item" value is retrieved.

Would you please let me know what I forget?

Thanks.


Sincerely,
Shinwoo Kim.


2011/3/18 Daniel Juyung Seo 

> +3 !
> Using group data in theme looks better because it reduces source-gui
> dependences.
>
> group { name: "xx";
>   data.item: "count" "3";
>
> You can fetch this data from c source using edje_object_data_get() API.
> Please check other widgets for a reference.
>
> I checked the patch very briefly and here are some comments.
>
> 1. Indentation.
> ex) line 250 in elm_diskselector.diff
>
> 2. Blank lines.
>   There are 2 blank lines at the end of diff file. 396, 397 lines.
>
> 3. Diff file.
>   I think there is no rule for this but you can merge two diff files
> to one diff file
>   because they are patches for a one feature and one library(elementary).
>
> 4. Sample code.
>   It will be better to have a sample code for a new feature in
> elementary_test.
>
> Other than that, looks ok :)
>
> Thanks.
> Daniel Juyung Seo (SeoZ)
>
> On Fri, Mar 18, 2011 at 5:57 AM, Tiago Falcao 
> wrote:
> > +2 !
> >
> > When had see this widget in first time, I imagined it with option to
> > many items but ever configured in theme.
> > If i'm right, this widget is a lot dependent of code and less of theme :(
> >
> > What you thing about this, Shinwoo Kim?
> > Gustavo suggested the easiest way, use group data.
> >
> > Thanks.
> >
> >
> > On Thu, Mar 17, 2011 at 4:47 PM, Gustavo Sverzut Barbieri
> >  wrote:
> >> On Thu, Mar 17, 2011 at 7:42 PM, Bruno Dilly 
> wrote:
> >>> On Thu, Mar 17, 2011 at 10:45 AM, cnook  wrote:
>  Dear All,
> >>>
> >>> Hi Shinwoo Kim,
> >>>
> 
>  This is Shinwoo Kim, learned that I could contribute to EFL! :)
>  I'm pleased to inform you that the patch for the "elm_diskselector".
> 
>  Until now, the "elm_diskselector" only display 3 items at once,
>  if you accept this patch, the "elm_diskselector" can display more than
> 3
>  items.
> >>>
> >>> Displaying more than 3 items is a nice improvement.
> >>> What do you think about the idea of getting the number of items to be
> >>> displayed from the theme ?
> >>>
> >>> Anyway, there is a typo on documentation (param num). Maybe a getter
> >>> could be useful as well.
> >>
> >> +1 to get it from theme!
> >>
> >> I did something similar for ephoto in some older version, it had
> >> couple of swallow parts defined, like "elm.swallow.p%d", and a
> >> data.item: "count" "3", thus it would fill 3 swallows.
> >>
> >> I believe this is something up to the theme as it has the knowledge on
> >> how to pack more items.
> >>
> >>
> >> --
> >> Gustavo Sverzut Barbieri
> >> http://profusion.mobi embedded systems
> >> --
> >> MSN: barbi...@gmail.com
> >> Skype: gsbarbieri
> >> Mobile: +55 (19) 9225-2202
> >>
> >>
> --
> >> Colocation vs. Managed Hosting
> >> A question and answer guide to determining the best fit
> >> for your organization - today and in the future.
> >> http://p.sf.net/sfu/internap-sfd2d
> >> ___
> >> enlightenment-devel mailing list
> >> enlightenment-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>
> >
> >
> >
> > --
> > Tiago Rezende Campos Falcão
> > http://www.tiagofalcao.com
> > --
> > ProFUSION | embedded systems
> > Computer Systems Laboratory - IC - Unicamp
> > Grupo Pró Software Livre - Unicamp
> > Laboratory of Information Systems - IC - Unicamp
> >
> >
> --
> > Colocation vs. Managed Hosting
> > A question and answer guide to determining the best fit
> > for your organization - today and in the future.
> > http://p.sf.net/sfu/internap-sfd2d
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Patch] Display more than 3 items

[Daniel Juyung Seo]

Check the _theme_hook().
:)

Thanks.
Daniel Juyung Seo (SeoZ)

On Sat, Mar 19, 2011 at 1:53 PM, cnook  wrote:
> Dear All,
>
> Hi~
>
> Thanks for your response.
>
> I have tried to use "data.item" and edje_object_data_get() API. It works
> fine. :)
>
> But I met a problem. When I use a new style for elm_diskselector,
> edje_object_data_get() cannot retrieve "data.item" of new style.
>
> Only original (default) "data.item" value is retrieved.
>
> Would you please let me know what I forget?
>
> Thanks.
>
>
> Sincerely,
> Shinwoo Kim.
>
>
> 2011/3/18 Daniel Juyung Seo 
>>
>> +3 !
>> Using group data in theme looks better because it reduces source-gui
>> dependences.
>>
>> group { name: "xx";
>>   data.item: "count" "3";
>>
>> You can fetch this data from c source using edje_object_data_get() API.
>> Please check other widgets for a reference.
>>
>> I checked the patch very briefly and here are some comments.
>>
>> 1. Indentation.
>> ex) line 250 in elm_diskselector.diff
>>
>> 2. Blank lines.
>>   There are 2 blank lines at the end of diff file. 396, 397 lines.
>>
>> 3. Diff file.
>>   I think there is no rule for this but you can merge two diff files
>> to one diff file
>>   because they are patches for a one feature and one library(elementary).
>>
>> 4. Sample code.
>>   It will be better to have a sample code for a new feature in
>> elementary_test.
>>
>> Other than that, looks ok :)
>>
>> Thanks.
>> Daniel Juyung Seo (SeoZ)
>>
>> On Fri, Mar 18, 2011 at 5:57 AM, Tiago Falcao 
>> wrote:
>> > +2 !
>> >
>> > When had see this widget in first time, I imagined it with option to
>> > many items but ever configured in theme.
>> > If i'm right, this widget is a lot dependent of code and less of theme
>> > :(
>> >
>> > What you thing about this, Shinwoo Kim?
>> > Gustavo suggested the easiest way, use group data.
>> >
>> > Thanks.
>> >
>> >
>> > On Thu, Mar 17, 2011 at 4:47 PM, Gustavo Sverzut Barbieri
>> >  wrote:
>> >> On Thu, Mar 17, 2011 at 7:42 PM, Bruno Dilly 
>> >> wrote:
>> >>> On Thu, Mar 17, 2011 at 10:45 AM, cnook  wrote:
>>  Dear All,
>> >>>
>> >>> Hi Shinwoo Kim,
>> >>>
>> 
>>  This is Shinwoo Kim, learned that I could contribute to EFL! :)
>>  I'm pleased to inform you that the patch for the "elm_diskselector".
>> 
>>  Until now, the "elm_diskselector" only display 3 items at once,
>>  if you accept this patch, the "elm_diskselector" can display more
>>  than 3
>>  items.
>> >>>
>> >>> Displaying more than 3 items is a nice improvement.
>> >>> What do you think about the idea of getting the number of items to be
>> >>> displayed from the theme ?
>> >>>
>> >>> Anyway, there is a typo on documentation (param num). Maybe a getter
>> >>> could be useful as well.
>> >>
>> >> +1 to get it from theme!
>> >>
>> >> I did something similar for ephoto in some older version, it had
>> >> couple of swallow parts defined, like "elm.swallow.p%d", and a
>> >> data.item: "count" "3", thus it would fill 3 swallows.
>> >>
>> >> I believe this is something up to the theme as it has the knowledge on
>> >> how to pack more items.
>> >>
>> >>
>> >> --
>> >> Gustavo Sverzut Barbieri
>> >> http://profusion.mobi embedded systems
>> >> --
>> >> MSN: barbi...@gmail.com
>> >> Skype: gsbarbieri
>> >> Mobile: +55 (19) 9225-2202
>> >>
>> >>
>> >> --
>> >> Colocation vs. Managed Hosting
>> >> A question and answer guide to determining the best fit
>> >> for your organization - today and in the future.
>> >> http://p.sf.net/sfu/internap-sfd2d
>> >> ___
>> >> enlightenment-devel mailing list
>> >> enlightenment-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>> >>
>> >
>> >
>> >
>> > --
>> > Tiago Rezende Campos Falcão
>> > http://www.tiagofalcao.com
>> > --
>> > ProFUSION | embedded systems
>> > Computer Systems Laboratory - IC - Unicamp
>> > Grupo Pró Software Livre - Unicamp
>> > Laboratory of Information Systems - IC - Unicamp
>> >
>> >
>> > --
>> > Colocation vs. Managed Hosting
>> > A question and answer guide to determining the best fit
>> > for your organization - today and in the future.
>> > http://p.sf.net/sfu/internap-sfd2d
>> > ___
>> > enlightenment-devel mailing list
>> > enlightenment-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>> >
>
>

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://

Re: [E-devel] GSoC 2011: sitting this one out....

[Daniel Juyung Seo]

Oh.. It is so sad to hear that we haven't selected.
I still welcome GSoC and hope to be a mentor next time.
Thanks for you and other's effort.

Daniel Juyung Seo (SeoZ)


On Sat, Mar 19, 2011 at 4:55 AM, Ravenlock  wrote:
> All,
>
> I am quite disappointed to report that we have not been selected for
> Google Summer of Code this year.  Google is only able to accept a
> certain number of mentoring organizations each year and they always
> receive many more applications than they can accommodate.
>
> There is an IRC meeting scheduled with Google administrators on March
> 22nd at which time the rejected organizations will have an opportunity
> to learn why it is they did not make the cut.  I will be sure to attend
> the meeting.
>
> We have had successful GSoC years in the past and we look forward to
> applying again in the future in order to participate again.
>
> --
> Regards,
> Ravenlock
>
>
>
> --
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: discomfitor IN trunk/eina: . src/lib

[Vincent Torri]

On Sat, 19 Mar 2011, Gustavo Sverzut Barbieri wrote:


On Fri, Mar 18, 2011 at 10:02 PM, Enlightenment SVN
 wrote:

Log:
use stringshare in eina_error
 the only restriction here is that eina_error_msg_register cannot be used 
internally by eina prior to stringshare init, but since this does not happen 
currently there is no problem :)


I guess this will cause dependency problems as eina_error is not
supposed to depend on things like stringshare that depends on mempool.


i agree

Vincent--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: discomfitor IN trunk/eina: . src/lib

[Mike Blumenkrantz]

On Sat, 19 Mar 2011 07:37:48 +0100 (CET)
Vincent Torri  wrote:

> 
> 
> On Sat, 19 Mar 2011, Gustavo Sverzut Barbieri wrote:
> 
> > On Fri, Mar 18, 2011 at 10:02 PM, Enlightenment SVN
> >  wrote:
> >> Log:
> >> use stringshare in eina_error
> >>  the only restriction here is that eina_error_msg_register cannot be used
> >> internally by eina prior to stringshare init, but since this does not
> >> happen currently there is no problem :)
> >
> > I guess this will cause dependency problems as eina_error is not
> > supposed to depend on things like stringshare that depends on mempool.
> 
> i agree
> 
> Vincent
that will only be the case if people go adding allocated error messages in
internal eina modules that get initialized before stringshare.

-- 
Mike Blumenkrantz
Zentific: NULL pointer dereferences now 50% off!

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel