[E-devel] [PATCH] elfe: update to new elementary API

[Martin Jansa]

Signed-off-by: Martin Jansa 
---
 E-MODULES-EXTRA/elfe/src/allapps.c |   18 +-
 1 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/E-MODULES-EXTRA/elfe/src/allapps.c 
b/E-MODULES-EXTRA/elfe/src/allapps.c
index a1ae04a..1feaad8 100644
--- a/E-MODULES-EXTRA/elfe/src/allapps.c
+++ b/E-MODULES-EXTRA/elfe/src/allapps.c
@@ -45,7 +45,7 @@ _label_get(void *data, Evas_Object *obj __UNUSED__, const 
char *part __UNUSED__)
 }
 
 static Evas_Object *
-_icon_get(void *data, Evas_Object *obj, const char *part)
+_content_get(void *data, Evas_Object *obj, const char *part)
 {
Evas_Object *ic = NULL;
Elfe_Grid_Item *gitem = data;
@@ -84,7 +84,7 @@ _gl_longpress(void *data, Evas_Object *obj __UNUSED__, void 
*event_info)
 
evas_object_smart_callback_call(allapps->box,
   "entry,longpressed", gitem->menu);
-   elm_gengrid_item_selected_set(it, EINA_FALSE);
+   elm_gen_item_selected_set(it, EINA_FALSE);
 }
 
 static void
@@ -97,7 +97,7 @@ _widget_longpress(void *data, Evas_Object *obj __UNUSED__, 
void *event_info)
printf("Send widget longpressed\n");
evas_object_smart_callback_call(allapps->box,
   "gadget,longpressed", (void*)name);
-   elm_genlist_item_selected_set(it, EINA_FALSE);
+   elm_gen_item_selected_set(it, EINA_FALSE);
 }
 
 static void
@@ -107,7 +107,7 @@ _item_selected(void *data, Evas_Object *obj __UNUSED__, 
void *event_info)
Elm_Gengrid_Item *it = event_info;
 
evas_object_smart_callback_call(gitem->allapps->box, "item,selected", 
gitem->menu);
-   elm_gengrid_item_selected_set(it, EINA_FALSE);
+   elm_gen_item_selected_set(it, EINA_FALSE);
 }
 
 
@@ -267,7 +267,7 @@ elfe_allapps_add(Evas_Object *parent)
ic = elm_icon_add(bt);
elm_icon_file_set(ic, elfe_home_cfg->theme, "icon/applications");
evas_object_show(ic);
-   elm_button_icon_set(bt, ic);
+   elm_button_content_set(bt, ic);
evas_object_show(bt);
elm_box_pack_end(allapps->selector, bt);
evas_object_smart_callback_add(bt, "clicked", _apps_clicked_cb, allapps);
@@ -282,7 +282,7 @@ elfe_allapps_add(Evas_Object *parent)
ic = elm_icon_add(bt);
elm_icon_file_set(ic, elfe_home_cfg->theme, "icon/widgets");
evas_object_show(ic);
-   elm_button_icon_set(bt, ic);
+   elm_button_content_set(bt, ic);
evas_object_show(bt);
elm_box_pack_end(allapps->selector, bt);
evas_object_smart_callback_add(bt, "clicked", _widgets_clicked_cb, allapps);
@@ -297,7 +297,7 @@ elfe_allapps_add(Evas_Object *parent)
ic = elm_icon_add(bt);
elm_icon_file_set(ic, elfe_home_cfg->theme, "icon/configuration");
evas_object_show(ic);
-   elm_button_icon_set(bt, ic);
+   elm_button_content_set(bt, ic);
evas_object_show(bt);
elm_box_pack_end(allapps->selector, bt);
evas_object_smart_callback_add(bt, "clicked", _config_clicked_cb, allapps);
@@ -320,7 +320,7 @@ elfe_allapps_add(Evas_Object *parent)
  _obj_del_cb, allapps);
 
elm_gengrid_multi_select_set(allapps->grid, EINA_FALSE);
-   elm_gengrid_bounce_set(allapps->grid, EINA_FALSE, EINA_TRUE);
+   elm_gen_bounce_set(allapps->grid, EINA_FALSE, EINA_TRUE);
 
evas_object_size_hint_weight_set(allapps->grid, EVAS_HINT_EXPAND, 
EVAS_HINT_EXPAND);
evas_object_size_hint_align_set(allapps->grid, EVAS_HINT_FILL, 
EVAS_HINT_FILL);
@@ -331,7 +331,7 @@ elfe_allapps_add(Evas_Object *parent)
 
app_itc.item_style = "default";
app_itc.func.label_get = _label_get;
-   app_itc.func.icon_get  = _icon_get;
+   app_itc.func.content_get  = _content_get;
app_itc.func.state_get = NULL;
app_itc.func.del   = NULL;
 
-- 
1.7.7.1


--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [PATCH] ecore: fix build with uclibc

[Martin Jansa]

Signed-off-by: Martin Jansa 
---
 ecore/src/lib/ecore_con/ecore_con_info.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/ecore/src/lib/ecore_con/ecore_con_info.c 
b/ecore/src/lib/ecore_con/ecore_con_info.c
index e20f788..62ce6bf 100644
--- a/ecore/src/lib/ecore_con/ecore_con_info.c
+++ b/ecore/src/lib/ecore_con/ecore_con_info.c
@@ -289,7 +289,7 @@ ecore_con_info_get(Ecore_Con_Server *svr,
 
 err = write(fd[1], "", 1);
 close(fd[1]);
-#ifdef __USE_ISOC99
+#if defined(__USE_ISOC99) && !defined(__UCLIBC__)
 _Exit(0);
 #else
 _exit(0);
-- 
1.7.7.1


--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] RFC: E17 Release

[Christopher Michael]

On 10/29/11 01:28, Carsten Haitzler (The Rasterman) wrote:
> On Sat, 29 Oct 2011 00:51:53 -0400 Christopher Michael
> said:
>
>> Well mate, slap it into svn somewhere and we can all jump into the fun
>> ;) (time permitting of course).
>
> i will - this weekend, i hope.
>
Cool :)

>> Agreed. But to 'jump the gun' and release early (read: earlier than
>> ready) at this stage is just silly. Take a little more time, finish the
>> work properly and have a Good release !! rather than a half-arsed one.
>> Hell, we've hammered on this for more years than I care to
>> count...what's a few more months ?? ;)
>
> thats actually another point - its not months - its weeks.
>
Well, not counting the exact time, my point still stands...why rush it 
out when we're this close ?? ;)

dh


--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] RFC: E17 Release

[The Rasterman]

On Sat, 29 Oct 2011 00:51:53 -0400 Christopher Michael 
said:

> Well mate, slap it into svn somewhere and we can all jump into the fun 
> ;) (time permitting of course).

i will - this weekend, i hope.

> Agreed. But to 'jump the gun' and release early (read: earlier than 
> ready) at this stage is just silly. Take a little more time, finish the 
> work properly and have a Good release !! rather than a half-arsed one. 
> Hell, we've hammered on this for more years than I care to 
> count...what's a few more months ?? ;)

thats actually another point - its not months - its weeks.

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


--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] RFC: E17 Release

[Christopher Michael]

On 10/29/11 00:44, Carsten Haitzler (The Rasterman) wrote:
> On Sat, 29 Oct 2011 00:25:55 -0400 Christopher Michael
> said:
>
>> On 10/28/11 22:23, Carsten Haitzler (The Rasterman) wrote:
>>> On Fri, 28 Oct 2011 22:46:55 +0200 Cedric BAIL   said:
>>>
>>> i'll post here as a summary. what k-s wants is to just release e17-as is
>>> after fixing some efm bugs. who agrees with that? everything stays as-is.
>>>
>> Sorry, cannot say that I agree. While e17 may be Close to release, to
>> put it 'out' now is premature imo. There are still a few things that
>> need fixing and/or ironing out.
>>
>>> the reason xrandr is on the todo is that there are many complaints and
>>> questions about how to get multi screen to work and we have no solution.
>>>
>>> the reason taskbar is there is because engage is compositing based
>>> realistically and we have to work without, and we again have had enough
>>> users complain and ask for a way to switch tasks.
>>>
>> What about the taskbar module ? Anyone know it's current 'status' ? Is
>> it usable for the average person ? Are there some issues remaining ? Are
>> they simple bug fixes ?? I'd lean more toward including it (rather than
>> engage) for the simple fact that taskbar does not 'require' compositing,
>> and severs the purpose for the 'average joe'.
>
> i actually read its code - it's mostly ok, but it has lurking bugs like not
> reffing e border objects. i've already begun a new tb code in my e tree but i
> also need to revamp its horizontal (and vertical) layout as well as add a
> feature to gadcon to make it work sensibly and not make shelf expand beyond 
> the
> bounds of the screen. i've already started here and my only goal is to make a
> workable taskbar that isnt going to fall over in cases and then move on.
>
Well mate, slap it into svn somewhere and we can all jump into the fun 
;) (time permitting of course).

>>> the reason efm is on the list is its mostly working and usable as a simple
>>> filemanager - that was its point. it needs some bugs fixed.
>>>
>>> the reason keymap config is there is for all those europeans (and a few
>>> others) with odd keymaps and people have no clue how to configure this on a
>>> command-line or in config files. the other todo items could get dropped,
>>> though theme does need to be polished.
>>>
>>> this wasnt unilaterally decided by me. i believe in making a good attempt
>>> at a quality release. gustavo just believes in dumping out whatever we have.
>> This is where gustavo and I disagree. I'm w/ you raster...would rather
>> have a quality product to release, rather than taking the
>> short/quick/easy way out and just 'release what we have'. If we take the
>> later route and just release things 'as they are', then we could end up
>> getting a reputation of premature release (gnome3, unity, and other such
>> junk)...which I (for one) would rather avoid. Better to take the extra
>> time and get things right. Oh I know I will get the "He's just in
>> raster's camp anyway" people/complaints...and I'm fine with that simply
>> because it's the right way to go about it. Why release something that is
>> incomplete/half-arsed ??
>
> that's indeed my point - and we are so CLOSE to being "done". it's impatience
> at the last leg of the race.
>
Agreed. But to 'jump the gun' and release early (read: earlier than 
ready) at this stage is just silly. Take a little more time, finish the 
work properly and have a Good release !! rather than a half-arsed one. 
Hell, we've hammered on this for more years than I care to 
count...what's a few more months ?? ;)

dh

>> dh
>>
>>
>>all the
>>> bitching about gnome and others will happen to us if we don't provide these
>>> basics that gnome etc. already DO. to many people we are useless. these are
>>> not new fangled ideas or standards - this is old hat that we haven't
>>> covered. so how do u expect to make those people happy and try or stay with
>>> e when we are not functional in some key aspects?
>>>
>>> get these above done and we can do an alpha.
>>>
 On Fri, Oct 28, 2011 at 9:19 PM, Mike Blumenkrantz
 wrote:
> On Fri, 28 Oct 2011 11:07:45 -0200
> Gustavo Sverzut Barbieri   wrote:
>> I'm writing this mail so it's unified and everyone can opine without
>> being in one place at one time (IRC/#edevelop).
>>
>> Recently I've talked to people and while I tried to express it at IRC,
>> raster just got pissed and left. Later people would join and agree
>> with me... so while I'm looking like a jerk I guess I'm not alone in
>> there. I'll try to be as clear and short as possible.
>>
>> WHY RELEASE?
>>  1. to clarify we know some snapshot is usable. This will get us in
>> more distributions by default.
> good
>>  2. to remove that stupid karma over the 17 number if e. Will help
>> people that do not track us closely to know we're reasonable serious.
> people will probably still call it e17 even when we're on e20
>

Re: [E-devel] elev8 + dbus

[The Rasterman]

On Sat, 29 Oct 2011 06:26:16 +0200 "Sanjeev B.A."  said:

> elev8 currently using ecore_con for http. I found it convenient to use
> ecore_con rather than curl (especially the response buffer handling)
> I haven't gone through e_dbus API but I am inclined to write the bindings
> based on e_dbus.

that would be right. the js could can be much easier due to introspection in
dbus and being able to generate a js object based on the instrospected info.

> Regards,
> Sanjeev
> 
> 
> 
> On Sat, Oct 29, 2011 at 12:26 AM, Gustavo Sverzut Barbieri <
> barbi...@profusion.mobi> wrote:
> 
> > On Fri, Oct 28, 2011 at 6:50 PM, Cedric BAIL  wrote:
> > > Hi,
> > >
> > > On Fri, Oct 28, 2011 at 3:16 PM, Gustavo Sverzut Barbieri
> > >  wrote:
> > >> Do you have plans to add DBus bindings to Elev8? Particularly
> > >> interested in ObjectManager and related support to make it easy to
> > >> access most system services (they are being converted to this standard
> > >> as Glib standardizes this method).
> > >
> > > What is this ObjectManager things ? I tried to do a quick google and
> > > ended up with some pointer to Windows, so either Vincent was able to
> > > drive Glib folks to embrace the evil or I didn't find the right
> > > pointer...
> >
> > http://davidz25.blogspot.com/2011/09/new-d-bus-features-in-glib-230.html
> >
> > I'm trying to find sponsors for this in e_dbus as well. As in glib, it
> > should be doable with a codegen, but in elev8 it needs nothing.
> >
> >
> >
> > >> I plan to write small tests for PulseAudio, ConnMan and BlueZ using
> > >> it. But there are also Tracker, MPRIS, UPower, UDisks, Telepathy and
> > >> others using it as well.
> > >
> > > Yeah, it will really make sense to have all of them, it will really
> > > start to be time consuming to maintain that. Do you have any idea how
> > > we could automate it ?
> >
> > See above. With ObjectManager (not all services are using it YET) and
> > DBus introspection we could easily generate C code to get the
> > properties and notify of signals. If you read e_bluez and e_connman
> > they are basically copy & paste of each others and should be the best
> > users of e_dbus nowadays... (except some possible copy & paste bugs).
> > It is VERY boring to keep in sync with upstream api.
> >
> > --
> > Gustavo Sverzut Barbieri
> > http://profusion.mobi embedded systems
> > --
> > MSN: barbi...@gmail.com
> > Skype: gsbarbieri
> > Mobile: +55 (19) 9225-2202
> >
> >
> > --
> > The demand for IT networking professionals continues to grow, and the
> > demand for specialized networking skills is growing even more rapidly.
> > Take a complimentary Learning@Cisco Self-Assessment and learn
> > about Cisco certifications, training, and career opportunities.
> > http://p.sf.net/sfu/cisco-dev2dev
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> --
> Get your Android app more play: Bring it to the BlackBerry PlayBook 
> in minutes. BlackBerry App World™ now supports Android™ Apps 
> for the BlackBerry® PlayBook™. Discover just how easy and simple 
> it is! http://p.sf.net/sfu/android-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


--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] RFC: E17 Release

[The Rasterman]

On Sat, 29 Oct 2011 00:25:55 -0400 Christopher Michael 
said:

> On 10/28/11 22:23, Carsten Haitzler (The Rasterman) wrote:
> > On Fri, 28 Oct 2011 22:46:55 +0200 Cedric BAIL  said:
> >
> > i'll post here as a summary. what k-s wants is to just release e17-as is
> > after fixing some efm bugs. who agrees with that? everything stays as-is.
> >
> Sorry, cannot say that I agree. While e17 may be Close to release, to 
> put it 'out' now is premature imo. There are still a few things that 
> need fixing and/or ironing out.
> 
> > the reason xrandr is on the todo is that there are many complaints and
> > questions about how to get multi screen to work and we have no solution.
> >
> > the reason taskbar is there is because engage is compositing based
> > realistically and we have to work without, and we again have had enough
> > users complain and ask for a way to switch tasks.
> >
> What about the taskbar module ? Anyone know it's current 'status' ? Is 
> it usable for the average person ? Are there some issues remaining ? Are 
> they simple bug fixes ?? I'd lean more toward including it (rather than 
> engage) for the simple fact that taskbar does not 'require' compositing, 
> and severs the purpose for the 'average joe'.

i actually read its code - it's mostly ok, but it has lurking bugs like not
reffing e border objects. i've already begun a new tb code in my e tree but i
also need to revamp its horizontal (and vertical) layout as well as add a
feature to gadcon to make it work sensibly and not make shelf expand beyond the
bounds of the screen. i've already started here and my only goal is to make a
workable taskbar that isnt going to fall over in cases and then move on.

> > the reason efm is on the list is its mostly working and usable as a simple
> > filemanager - that was its point. it needs some bugs fixed.
> >
> > the reason keymap config is there is for all those europeans (and a few
> > others) with odd keymaps and people have no clue how to configure this on a
> > command-line or in config files. the other todo items could get dropped,
> > though theme does need to be polished.
> >
> > this wasnt unilaterally decided by me. i believe in making a good attempt
> > at a quality release. gustavo just believes in dumping out whatever we have.
> This is where gustavo and I disagree. I'm w/ you raster...would rather 
> have a quality product to release, rather than taking the 
> short/quick/easy way out and just 'release what we have'. If we take the 
> later route and just release things 'as they are', then we could end up 
> getting a reputation of premature release (gnome3, unity, and other such 
> junk)...which I (for one) would rather avoid. Better to take the extra 
> time and get things right. Oh I know I will get the "He's just in 
> raster's camp anyway" people/complaints...and I'm fine with that simply 
> because it's the right way to go about it. Why release something that is 
> incomplete/half-arsed ??

that's indeed my point - and we are so CLOSE to being "done". it's impatience
at the last leg of the race.

> dh
> 
> 
>   all the
> > bitching about gnome and others will happen to us if we don't provide these
> > basics that gnome etc. already DO. to many people we are useless. these are
> > not new fangled ideas or standards - this is old hat that we haven't
> > covered. so how do u expect to make those people happy and try or stay with
> > e when we are not functional in some key aspects?
> >
> > get these above done and we can do an alpha.
> >
> >> On Fri, Oct 28, 2011 at 9:19 PM, Mike Blumenkrantz
> >> wrote:
> >>> On Fri, 28 Oct 2011 11:07:45 -0200
> >>> Gustavo Sverzut Barbieri  wrote:
>  I'm writing this mail so it's unified and everyone can opine without
>  being in one place at one time (IRC/#edevelop).
> 
>  Recently I've talked to people and while I tried to express it at IRC,
>  raster just got pissed and left. Later people would join and agree
>  with me... so while I'm looking like a jerk I guess I'm not alone in
>  there. I'll try to be as clear and short as possible.
> 
>  WHY RELEASE?
>  1. to clarify we know some snapshot is usable. This will get us in
>  more distributions by default.
> >>> good
>  2. to remove that stupid karma over the 17 number if e. Will help
>  people that do not track us closely to know we're reasonable serious.
> >>> people will probably still call it e17 even when we're on e20
>  3. we can start to bring in new technology without delaying it even
>  further (ie: elm and scripting language - js/elev8)
> >>> not really a valid reason to release, you can see it did wonders for gnome
> >>
> >> http://www.phoronix.com/scan.php?page=article&item=gnome_survey_part1&num=1
> >>
> >> I don't really see the link with what you are saying.
> >>
>  WHY NOT RELEASE?
>  1. there are both bugs (eg: efm)
> >>> cedric has said a number of times that he'll be working on efm after he
> >>>

Re: [E-devel] E SVN: raster trunk/e/src/bin

[Mike Blumenkrantz]

On Fri, 28 Oct 2011 21:36:32 -0700
"Enlightenment SVN"  wrote:

> Log:
> make backlight code a bit more generic with a list of sysfs files to
>   look at to get backlight working.
>   
>   
> 
> Author:   raster
> Date: 2011-10-28 21:36:32 -0700 (Fri, 28 Oct 2011)
> New Revision: 64503
> Trac: http://trac.enlightenment.org/e/changeset/64503
> 
> Modified:
>   trunk/e/src/bin/e_backlight.c trunk/e/src/bin/e_backlight_main.c 
> 
> Modified: trunk/e/src/bin/e_backlight.c
> ===
> --- trunk/e/src/bin/e_backlight.c 2011-10-29 04:32:24 UTC (rev 64502)
> +++ trunk/e/src/bin/e_backlight.c 2011-10-29 04:36:32 UTC (rev 64503)
> @@ -13,10 +13,12 @@
>  static E_Backlight_Mode bl_mode = E_BACKLIGHT_MODE_NORMAL;
>  static int sysmode = MODE_NONE;
>  static Ecore_Animator *bl_anim = NULL;
> +static const char *bl_sysvalmax = NULL;
>  static const char *bl_sysval = NULL;
>  static Ecore_Event_Handler *bl_sys_exit_handler = NULL;
>  static Ecore_Exe *bl_sys_set_exe = NULL;
>  static Eina_Bool bl_sys_pending_set = EINA_FALSE;
> +static Eina_Bool bl_sys_set_exe_ready = EINA_TRUE;
>  
>  static void _e_backlight_update(E_Zone *zone);
>  static void _e_backlight_set(E_Zone *zone, double val);
> @@ -42,6 +44,8 @@
>  {
> if (bl_anim) ecore_animator_del(bl_anim);
> bl_anim = NULL;
> +   if (bl_sysval) eina_stringshare_del(bl_sysvalmax);
> +   bl_sysvalmax = NULL;
> if (bl_sysval) eina_stringshare_del(bl_sysval);
> bl_sysval = NULL;
> if (bl_sys_exit_handler) ecore_event_handler_del(bl_sys_exit_handler);
> @@ -252,87 +256,128 @@
> return maxval;
>  }
>  
> +typedef struct _Bl_Entry
> +{
> +   char type;
> +   const char *base;
> +   const char *max;
> +   const char *set;
> +} Bl_Entry;
> +
> +static const Bl_Entry search[] =
> +{
> +   { 'F', "/sys/devices/virtual/backlight/acpi_video0", "max_brightness",
> "brightness" },
> +   { 'D', "/sys/devices/virtual/backlight", "max_brightness", "brightness" },
> +   { 'F', "/sys/class/leds/lcd-backlight", "max_brightness", "brightness" },
> +   { 'F', "/sys/class/backlight/acpi_video0", "max_brightness",
> "brightness" },
> +   { 'D', "/sys/class/backlight", "max_brightness", "brightness" }
> +};
> +
>  static void
>  _bl_sys_find(void)
>  {
> -   int maxval = 0;
> -   const char *tryfile;
> -   
> -   if (bl_sysval) return;
> -   tryfile = "/sys/devices/virtual/backlight/acpi_video0/max_brightness";
> -   maxval = _bl_sys_num_get(tryfile);
> -   if (maxval > 0)
> +   int i, curlevel = 0;
> +   char *valstr;
> +   char file[4096] = "";
> +
> +   for (i = 0; i < (int)(sizeof(search) / sizeof(Bl_Entry)); i++)
>   {
> -bl_sysval = eina_stringshare_add(tryfile);
> -return;
> - }
> -   else
> - {
> -Eina_List *files;
> -const char *dir = "/sys/devices/virtual/backlight";
> +char buf[4096];
> +const Bl_Entry *b = &(search[i]);
>  
> -files = ecore_file_ls(dir);
> -if (files)
> +if (b->type == 'F')
>{
> - char *file;
> - 
> - EINA_LIST_FREE(files, file)
> + snprintf(buf, sizeof(buf), "%s/%s", b->base, b->set);
> + valstr = _bl_read_file(buf);
> + if (valstr)
> {
> -  if (!bl_sysval)
> +  curlevel = atoi(valstr);
> +  if (curlevel < 0)
>  {
> -   char buf[PATH_MAX];
> -   
> -   snprintf(buf, sizeof(buf), 
> -"%s/%s/max_brightness", dir, file);
> -   maxval = _bl_sys_num_get(buf);
> -   if (maxval > 0)
> -  bl_sysval = eina_stringshare_add(buf);
> +   free(valstr);
> +   valstr = NULL;
>  }
> -  free(file);
> +  else
> +{
> +   bl_sysval = eina_stringshare_add(buf);
> +   snprintf(file, sizeof(file), "%s/%s", b->base,
> b->max);
> +   bl_sysvalmax = eina_stringshare_add(file);
> +   free(valstr);
> +   valstr = NULL;
> +}
> }
>}
> -if (maxval <= 0)
> +else if (b->type == 'D')
>{
> - struct stat st;
> + DIR *dirp = opendir(b->base);
> + struct dirent *dp;
>   
> - tryfile = "/sys/class/leds/lcd-backlight/brightness";
> - if (stat(tryfile, &st) == 0)
> + if (dirp)
> {
> -  tryfile = "/sys/class/leds/lcd-backlight/max_brightness";
> -  bl_sysval = eina_stringshare_add(tryfile);
> -  maxval = _bl_sys_num_get(tryfile);
> -  if (maxval <

Re: [E-devel] Backlight module

[The Rasterman]

On Fri, 28 Oct 2011 23:48:49 +0200 eva...@evadim.ru said:

>   Hello!
> 
> I have question about backlight module it don't work for me for a log time.
> I look into it and found acpi paths a bit different [1] than in my system,
> so I correct it and module start working. In first hunk, I think, I see typo,
> but about paths I don't know what to do: Work it for somebody? May be some
> old kernels had this paths? How to make module work on old & new systems?
> Now I use kernel 3.* and my friends have paths like me.

i think that new kernels have dropped the old paths. i've made it a bit more
generic by using a list of places to look than whats in your patch - check svn
out now.


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


--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] RFC: E17 Release

[Christopher Michael]

On 10/28/11 22:58, David Seikel wrote:
> On Sat, 29 Oct 2011 11:23:37 +0900 Carsten Haitzler (The Rasterman)
>   wrote:
>
>> On Fri, 28 Oct 2011 22:46:55 +0200 Cedric BAIL
>> said:
>>
>> i'll post here as a summary. what k-s wants is to just release e17-as
>> is after fixing some efm bugs. who agrees with that? everything stays
>> as-is.
>
> We already have a plan, it's a good plan.  We should stick to it.
>
>> the reason taskbar is there is because engage is compositing based
>> realistically and we have to work without, and we again have had
>> enough users complain and ask for a way to switch tasks.
>
> Yep, need one that works just as good without compositing.  Or create a
> taskbar only, like we have ibar and ibox, maybe call it itask?  Er
> wait, itask-ng?  Um no, itask-ds9?  Then we can make one for mobiles and
> call it itask-voyager, and one for big companies and call it
> itask-enterprise. B-)
>
> I think there is room for both an all in one, and separate bars.
>
>> the reason efm is on the list is its mostly working and usable as a
>> simple filemanager - that was its point. it needs some bugs fixed.
>
> Agreed.
>
>> the reason keymap config is there is for all those europeans (and a
>> few others) with odd keymaps and people have no clue how to configure
>> this on a command-line or in config files. the other todo items could
>> get dropped, though theme does need to be polished.
>
> I'll put in my personal plug for being able to switch keyboard layouts
> WITHOUT changing languages.  So all my dvorak challenged friends can
> still use my computer.  They'll have to be able to touch type QWERTY,
> but I can live with that.  It's even harder to do this on the command
> line when the keyboard is mapped to something your are not familiar
> with.  lol
>
>> this wasnt unilaterally decided by me. i believe in making a good
>> attempt at a quality release. gustavo just believes in dumping out
>> whatever we have. all the bitching about gnome and others will happen
>> to us if we don't provide these basics that gnome etc. already DO. to
>> many people we are useless. these are not new fangled ideas or
>> standards - this is old hat that we haven't covered. so how do u
>> expect to make those people happy and try or stay with e when we are
>> not functional in some key aspects?
>>
>> get these above done and we can do an alpha.
>
> Works for me.
>
+1

> There was also mention of theme work, but the only part of the
> current default theme that has truly annoyed me so far is the desktop
> background.  So I replaced it with something boring.
>
Agree and disagree. Let me explain. While some people may not like the 
current default theme, it is (by it's nature) the most 'complete' theme 
that is available. Yea the desktop background sucks on it (sorry mate) 
but that is easily changeable by the average person. Now, having said 
that, I don't 'dislike' detour theme (as far as color scheme). What I do 
dislike about it is the overly large menus/menu items. (If you don't 
know what I mean, then load the default theme and look @ the menu/menu 
items. Then load detour and look @ it's menu/menu items). If detour 
theme had menus of a similar size as the default theme, then I would be 
much more in favor of detour, but as it sits no...the menus just waste 
too much space imo.

dh


--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] RFC: E17 Release

[Christopher Michael]

On 10/28/11 22:55, Michael Jennings wrote:
> On Saturday, 29 October 2011, at 11:23:37 (+0900),
> Carsten Haitzler wrote:
>
>> i'll post here as a summary. what k-s wants is to just release e17-as is 
>> after
>> fixing some efm bugs. who agrees with that? everything stays as-is.
>>
>> the reason xrandr is on the todo is that there are many complaints and
>> questions about how to get multi screen to work and we have no solution.
>>
>> the reason taskbar is there is because engage is compositing based 
>> realistically
>> and we have to work without, and we again have had enough users complain and
>> ask for a way to switch tasks.
>>
>> the reason efm is on the list is its mostly working and usable as a simple
>> filemanager - that was its point. it needs some bugs fixed.
>>
>> the reason keymap config is there is for all those europeans (and a few 
>> others)
>> with odd keymaps and people have no clue how to configure this on a
>> command-line or in config files. the other todo items could get dropped, 
>> though
>> theme does need to be polished.
>>
>> this wasnt unilaterally decided by me. i believe in making a good attempt at 
>> a
>> quality release. gustavo just believes in dumping out whatever we have. all 
>> the
>> bitching about gnome and others will happen to us if we don't provide these
>> basics that gnome etc. already DO. to many people we are useless. these are 
>> not
>> new fangled ideas or standards - this is old hat that we haven't covered. so
>> how do u expect to make those people happy and try or stay with e when we are
>> not functional in some key aspects?
>
> Absolutely correct.
>
> After 10 years of development, releasing nothing is far, far
> preferable to releasing something half-assed.
>
> I can hear the comments now.  "I've waited this long for crap?  10
> years, and this is the best they can do?  Never again!"
>
110 % agreed !!!

> If people are honestly that bent out of shape wanting a release, they
> should be hammering away on the TODO list.
Yup yup.

  Getting shit done is how a
> release will happen, not rehashing the same tired old argument every
> few months diverting time from more productive pursuits.
>
Ahmen...tired of hearing it (well that and the formatting wars).

dh

> Michael
>


--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] RFC: E17 Release

[Christopher Michael]

On 10/28/11 22:23, Carsten Haitzler (The Rasterman) wrote:
> On Fri, 28 Oct 2011 22:46:55 +0200 Cedric BAIL  said:
>
> i'll post here as a summary. what k-s wants is to just release e17-as is after
> fixing some efm bugs. who agrees with that? everything stays as-is.
>
Sorry, cannot say that I agree. While e17 may be Close to release, to 
put it 'out' now is premature imo. There are still a few things that 
need fixing and/or ironing out.

> the reason xrandr is on the todo is that there are many complaints and
> questions about how to get multi screen to work and we have no solution.
>
> the reason taskbar is there is because engage is compositing based 
> realistically
> and we have to work without, and we again have had enough users complain and
> ask for a way to switch tasks.
>
What about the taskbar module ? Anyone know it's current 'status' ? Is 
it usable for the average person ? Are there some issues remaining ? Are 
they simple bug fixes ?? I'd lean more toward including it (rather than 
engage) for the simple fact that taskbar does not 'require' compositing, 
and severs the purpose for the 'average joe'.

> the reason efm is on the list is its mostly working and usable as a simple
> filemanager - that was its point. it needs some bugs fixed.
>
> the reason keymap config is there is for all those europeans (and a few 
> others)
> with odd keymaps and people have no clue how to configure this on a
> command-line or in config files. the other todo items could get dropped, 
> though
> theme does need to be polished.
>
> this wasnt unilaterally decided by me. i believe in making a good attempt at a
> quality release. gustavo just believes in dumping out whatever we have.
This is where gustavo and I disagree. I'm w/ you raster...would rather 
have a quality product to release, rather than taking the 
short/quick/easy way out and just 'release what we have'. If we take the 
later route and just release things 'as they are', then we could end up 
getting a reputation of premature release (gnome3, unity, and other such 
junk)...which I (for one) would rather avoid. Better to take the extra 
time and get things right. Oh I know I will get the "He's just in 
raster's camp anyway" people/complaints...and I'm fine with that simply 
because it's the right way to go about it. Why release something that is 
incomplete/half-arsed ??

dh


  all the
> bitching about gnome and others will happen to us if we don't provide these
> basics that gnome etc. already DO. to many people we are useless. these are 
> not
> new fangled ideas or standards - this is old hat that we haven't covered. so
> how do u expect to make those people happy and try or stay with e when we are
> not functional in some key aspects?
>
> get these above done and we can do an alpha.
>
>> On Fri, Oct 28, 2011 at 9:19 PM, Mike Blumenkrantz  wrote:
>>> On Fri, 28 Oct 2011 11:07:45 -0200
>>> Gustavo Sverzut Barbieri  wrote:
 I'm writing this mail so it's unified and everyone can opine without
 being in one place at one time (IRC/#edevelop).

 Recently I've talked to people and while I tried to express it at IRC,
 raster just got pissed and left. Later people would join and agree
 with me... so while I'm looking like a jerk I guess I'm not alone in
 there. I'll try to be as clear and short as possible.

 WHY RELEASE?
 1. to clarify we know some snapshot is usable. This will get us in
 more distributions by default.
>>> good
 2. to remove that stupid karma over the 17 number if e. Will help
 people that do not track us closely to know we're reasonable serious.
>>> people will probably still call it e17 even when we're on e20
 3. we can start to bring in new technology without delaying it even
 further (ie: elm and scripting language - js/elev8)
>>> not really a valid reason to release, you can see it did wonders for gnome
>>
>> http://www.phoronix.com/scan.php?page=article&item=gnome_survey_part1&num=1
>>
>> I don't really see the link with what you are saying.
>>
 WHY NOT RELEASE?
 1. there are both bugs (eg: efm)
>>> cedric has said a number of times that he'll be working on efm after he
>>> finishes emotion soon, and I'll likely disable eeze mounting entirely for
>>> the release since libmount is not widely deployed and I was unable to get
>>> widespread testing until now.
 2. missing features (xrandr, taskbar, ...)
>>> * xrandr patches have been made and are on the list waiting for testing and
>>> review, so I'm not really sure why this is a "missing" feature.
>>> * New users will not be able to deal with E17 if it doesn't have a taskbar,
>>> end of story. Engage is in SVN now, it's usable and widely used already, it
>>> can be merged.
>>
>> No you can't ! Doesn't solve the problem for non composite use case
>> and as long as we don't make the compositer the only possible choice
>> we can't say that engage is the answer to that problem.
>>
>>> * I don't car

Re: [E-devel] elev8 + dbus

[Sanjeev B.A.]

elev8 currently using ecore_con for http. I found it convenient to use
ecore_con rather than curl (especially the response buffer handling)
I haven't gone through e_dbus API but I am inclined to write the bindings
based on e_dbus.

Regards,
Sanjeev



On Sat, Oct 29, 2011 at 12:26 AM, Gustavo Sverzut Barbieri <
barbi...@profusion.mobi> wrote:

> On Fri, Oct 28, 2011 at 6:50 PM, Cedric BAIL  wrote:
> > Hi,
> >
> > On Fri, Oct 28, 2011 at 3:16 PM, Gustavo Sverzut Barbieri
> >  wrote:
> >> Do you have plans to add DBus bindings to Elev8? Particularly
> >> interested in ObjectManager and related support to make it easy to
> >> access most system services (they are being converted to this standard
> >> as Glib standardizes this method).
> >
> > What is this ObjectManager things ? I tried to do a quick google and
> > ended up with some pointer to Windows, so either Vincent was able to
> > drive Glib folks to embrace the evil or I didn't find the right
> > pointer...
>
> http://davidz25.blogspot.com/2011/09/new-d-bus-features-in-glib-230.html
>
> I'm trying to find sponsors for this in e_dbus as well. As in glib, it
> should be doable with a codegen, but in elev8 it needs nothing.
>
>
>
> >> I plan to write small tests for PulseAudio, ConnMan and BlueZ using
> >> it. But there are also Tracker, MPRIS, UPower, UDisks, Telepathy and
> >> others using it as well.
> >
> > Yeah, it will really make sense to have all of them, it will really
> > start to be time consuming to maintain that. Do you have any idea how
> > we could automate it ?
>
> See above. With ObjectManager (not all services are using it YET) and
> DBus introspection we could easily generate C code to get the
> properties and notify of signals. If you read e_bluez and e_connman
> they are basically copy & paste of each others and should be the best
> users of e_dbus nowadays... (except some possible copy & paste bugs).
> It is VERY boring to keep in sync with upstream api.
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
>
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] RFC: E17 Release

[P Purkayastha]

On Saturday, October 29, 2011 10:23:37 AM UTC+8, The Rasterman Carsten 
Haitzler wrote:
>
> On Fri, 28 Oct 2011 22:46:55 +0200 Cedric BAIL  said:
>
> the reason taskbar is there is because engage is compositing based 
> realistically
> and we have to work without, and we again have had enough users complain 
> and
> ask for a way to switch tasks.

There are two different taskbars in the E-MODULES-EXTRA. One is itask and 
the other is taskbar.
taskbar is pretty basic but it works just fine.

itask can look like ibar and ibox, or like taskbar, but it is unable to 
show its own configuration option when you right click on it (by default it 
shows only the window's border menu). So it is harder to change its 
configuration.
--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] RFC: E17 Release

[Mike Blumenkrantz]

On Fri, 28 Oct 2011 22:46:55 +0200
Cedric BAIL  wrote:

> On Fri, Oct 28, 2011 at 9:19 PM, Mike Blumenkrantz  wrote:
> > On Fri, 28 Oct 2011 11:07:45 -0200
> > Gustavo Sverzut Barbieri  wrote:
> >> I'm writing this mail so it's unified and everyone can opine without
> >> being in one place at one time (IRC/#edevelop).
> >>
> >> Recently I've talked to people and while I tried to express it at IRC,
> >> raster just got pissed and left. Later people would join and agree
> >> with me... so while I'm looking like a jerk I guess I'm not alone in
> >> there. I'll try to be as clear and short as possible.
> >>
> >> WHY RELEASE?
> >>    1. to clarify we know some snapshot is usable. This will get us in
> >> more distributions by default.
> > good
> >>    2. to remove that stupid karma over the 17 number if e. Will help
> >> people that do not track us closely to know we're reasonable serious.
> > people will probably still call it e17 even when we're on e20
> >>    3. we can start to bring in new technology without delaying it even
> >> further (ie: elm and scripting language - js/elev8)
> > not really a valid reason to release, you can see it did wonders for gnome
> 
> http://www.phoronix.com/scan.php?page=article&item=gnome_survey_part1&num=1
> 
> I don't really see the link with what you are saying.
You were talking about this part, I assume?
[[[
37: 1. The complete ignorance and incompetence of the Gnome developpers; 
2. The toolkit; 
3. The entire UI.

Yes, dig into the where computers came from ASAP: 
1. Telegram devices; 
2. Logic processors.

Therefore a computer is there for: 
1. World Wide Web users; 
2. Applications.

And not for: 
1. Offline HTML 'apps'; 
2. Being a trophy for your shelf.

So what you need to do is: 
1. Create a serious programming platform; 
2. Make it a browser haven.

You think that Gnome is making it easyer for users, by applying (yet again, how
not surprising) an abstraction layer. "Oh this must be easyer to understand
than. *Beep!* WRONG!
]]]
> 
> >> WHY NOT RELEASE?
> >>    1. there are both bugs (eg: efm)
> > cedric has said a number of times that he'll be working on efm after he
> > finishes emotion soon, and I'll likely disable eeze mounting entirely for
> > the release since libmount is not widely deployed and I was unable to get
> > widespread testing until now.
> >>    2. missing features (xrandr, taskbar, ...)
> > * xrandr patches have been made and are on the list waiting for testing and
> > review, so I'm not really sure why this is a "missing" feature.
> > * New users will not be able to deal with E17 if it doesn't have a taskbar,
> > end of story. Engage is in SVN now, it's usable and widely used already, it
> > can be merged.
> 
> No you can't ! Doesn't solve the problem for non composite use case
> and as long as we don't make the compositer the only possible choice
> we can't say that engage is the answer to that problem.
It's better than nothing.
> 
> > * I don't care about keymap config since I'm american, but it seems
> > important for users to be able to type in their own language
> > * b&w is awful, we should switch to and iron out detourious for release
> 
> Yes, that's something we should do as soon as possible. As a side
> question, what is the status of that theme for elementary ? Because it
> would make sense to also do the switch for elementary at some point.
It works.
> 
> > * Improved connman support is a big sticking point for me. I strongly
> > believe that if the module does not improve now while it is actually a
> > blocker for release, it never will. To this end, it's missing 3 big
> > features that I can see people using: hidden network support, static ip
> > setting, and enterprise encryption. It's likely that this is not actually a
> > 6 month project as you have implied.
> 
> Well, I have been using connman module since now one year and there is
> only one place in the world where I would have liked to have a UI to
> set static IP and a VPN... I am sure that's raster is in that place
> most of the time like some of our user base :-) So not a strong
> requirement from my point of view, but maybe some people at Samsung
> could take over that item as of course you are all using E17 !
> 
> >> EXTRA DISCUSSIONS
> >>    * e_widgets is amazingly boring and gets in the way, people expect
> >> something like Elementary to help them. Or even better, for rarely
> >> used features like a mixer control dialog, xrandr dialog, connection
> >> manager configuration these things could be done with a high level
> >> language such as elev8. Thus lots of people would be motivated to help
> >> get more features in. But introducing this now would delay e17 even
> >> more, thus a no go.  (Personal note I'm highly demotivated to hack e17
> >> due this exact reason. Doing a mixer dialog in e_widget is like few
> >> days, in elev8 it should take me few hours -- easier to find than few
> >> days)
> > No argument here, though I think it's more an issue that e_widgets lac

Re: [E-devel] RFC: E17 Release

[David Seikel]

On Sat, 29 Oct 2011 11:23:37 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Fri, 28 Oct 2011 22:46:55 +0200 Cedric BAIL 
> said:
> 
> i'll post here as a summary. what k-s wants is to just release e17-as
> is after fixing some efm bugs. who agrees with that? everything stays
> as-is.

We already have a plan, it's a good plan.  We should stick to it.
 
> the reason taskbar is there is because engage is compositing based
> realistically and we have to work without, and we again have had
> enough users complain and ask for a way to switch tasks.

Yep, need one that works just as good without compositing.  Or create a
taskbar only, like we have ibar and ibox, maybe call it itask?  Er
wait, itask-ng?  Um no, itask-ds9?  Then we can make one for mobiles and
call it itask-voyager, and one for big companies and call it
itask-enterprise. B-)

I think there is room for both an all in one, and separate bars.

> the reason efm is on the list is its mostly working and usable as a
> simple filemanager - that was its point. it needs some bugs fixed.

Agreed.

> the reason keymap config is there is for all those europeans (and a
> few others) with odd keymaps and people have no clue how to configure
> this on a command-line or in config files. the other todo items could
> get dropped, though theme does need to be polished.

I'll put in my personal plug for being able to switch keyboard layouts
WITHOUT changing languages.  So all my dvorak challenged friends can
still use my computer.  They'll have to be able to touch type QWERTY,
but I can live with that.  It's even harder to do this on the command
line when the keyboard is mapped to something your are not familiar
with.  lol

> this wasnt unilaterally decided by me. i believe in making a good
> attempt at a quality release. gustavo just believes in dumping out
> whatever we have. all the bitching about gnome and others will happen
> to us if we don't provide these basics that gnome etc. already DO. to
> many people we are useless. these are not new fangled ideas or
> standards - this is old hat that we haven't covered. so how do u
> expect to make those people happy and try or stay with e when we are
> not functional in some key aspects?
> 
> get these above done and we can do an alpha. 

Works for me.

There was also mention of theme work, but the only part of the
current default theme that has truly annoyed me so far is the desktop
background.  So I replaced it with something boring.

-- 
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
--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] RFC: E17 Release

[Michael Jennings]

On Saturday, 29 October 2011, at 11:23:37 (+0900),
Carsten Haitzler wrote:

> i'll post here as a summary. what k-s wants is to just release e17-as is after
> fixing some efm bugs. who agrees with that? everything stays as-is.
> 
> the reason xrandr is on the todo is that there are many complaints and
> questions about how to get multi screen to work and we have no solution.
> 
> the reason taskbar is there is because engage is compositing based 
> realistically
> and we have to work without, and we again have had enough users complain and
> ask for a way to switch tasks.
> 
> the reason efm is on the list is its mostly working and usable as a simple
> filemanager - that was its point. it needs some bugs fixed.
> 
> the reason keymap config is there is for all those europeans (and a few 
> others)
> with odd keymaps and people have no clue how to configure this on a
> command-line or in config files. the other todo items could get dropped, 
> though
> theme does need to be polished.
> 
> this wasnt unilaterally decided by me. i believe in making a good attempt at a
> quality release. gustavo just believes in dumping out whatever we have. all 
> the
> bitching about gnome and others will happen to us if we don't provide these
> basics that gnome etc. already DO. to many people we are useless. these are 
> not
> new fangled ideas or standards - this is old hat that we haven't covered. so
> how do u expect to make those people happy and try or stay with e when we are
> not functional in some key aspects?

Absolutely correct.

After 10 years of development, releasing nothing is far, far
preferable to releasing something half-assed.

I can hear the comments now.  "I've waited this long for crap?  10
years, and this is the best they can do?  Never again!"

If people are honestly that bent out of shape wanting a release, they
should be hammering away on the TODO list.  Getting shit done is how a
release will happen, not rehashing the same tired old argument every
few months diverting time from more productive pursuits.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  
Linux Server/Cluster Admin, LBL.gov   Author, Eterm (www.eterm.org)
---
 "I feel wonderful because I see the love light in your eyes, and the
  wonder of it all is that you just don't realize how much I love
  you."   -- Eric Clapton, "Wonderful Tonight"

--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] RFC: E17 Release

[The Rasterman]

On Fri, 28 Oct 2011 22:46:55 +0200 Cedric BAIL  said:

i'll post here as a summary. what k-s wants is to just release e17-as is after
fixing some efm bugs. who agrees with that? everything stays as-is.

the reason xrandr is on the todo is that there are many complaints and
questions about how to get multi screen to work and we have no solution.

the reason taskbar is there is because engage is compositing based realistically
and we have to work without, and we again have had enough users complain and
ask for a way to switch tasks.

the reason efm is on the list is its mostly working and usable as a simple
filemanager - that was its point. it needs some bugs fixed.

the reason keymap config is there is for all those europeans (and a few others)
with odd keymaps and people have no clue how to configure this on a
command-line or in config files. the other todo items could get dropped, though
theme does need to be polished.

this wasnt unilaterally decided by me. i believe in making a good attempt at a
quality release. gustavo just believes in dumping out whatever we have. all the
bitching about gnome and others will happen to us if we don't provide these
basics that gnome etc. already DO. to many people we are useless. these are not
new fangled ideas or standards - this is old hat that we haven't covered. so
how do u expect to make those people happy and try or stay with e when we are
not functional in some key aspects?

get these above done and we can do an alpha. 

> On Fri, Oct 28, 2011 at 9:19 PM, Mike Blumenkrantz  wrote:
> > On Fri, 28 Oct 2011 11:07:45 -0200
> > Gustavo Sverzut Barbieri  wrote:
> >> I'm writing this mail so it's unified and everyone can opine without
> >> being in one place at one time (IRC/#edevelop).
> >>
> >> Recently I've talked to people and while I tried to express it at IRC,
> >> raster just got pissed and left. Later people would join and agree
> >> with me... so while I'm looking like a jerk I guess I'm not alone in
> >> there. I'll try to be as clear and short as possible.
> >>
> >> WHY RELEASE?
> >>    1. to clarify we know some snapshot is usable. This will get us in
> >> more distributions by default.
> > good
> >>    2. to remove that stupid karma over the 17 number if e. Will help
> >> people that do not track us closely to know we're reasonable serious.
> > people will probably still call it e17 even when we're on e20
> >>    3. we can start to bring in new technology without delaying it even
> >> further (ie: elm and scripting language - js/elev8)
> > not really a valid reason to release, you can see it did wonders for gnome
> 
> http://www.phoronix.com/scan.php?page=article&item=gnome_survey_part1&num=1
> 
> I don't really see the link with what you are saying.
> 
> >> WHY NOT RELEASE?
> >>    1. there are both bugs (eg: efm)
> > cedric has said a number of times that he'll be working on efm after he
> > finishes emotion soon, and I'll likely disable eeze mounting entirely for
> > the release since libmount is not widely deployed and I was unable to get
> > widespread testing until now.
> >>    2. missing features (xrandr, taskbar, ...)
> > * xrandr patches have been made and are on the list waiting for testing and
> > review, so I'm not really sure why this is a "missing" feature.
> > * New users will not be able to deal with E17 if it doesn't have a taskbar,
> > end of story. Engage is in SVN now, it's usable and widely used already, it
> > can be merged.
> 
> No you can't ! Doesn't solve the problem for non composite use case
> and as long as we don't make the compositer the only possible choice
> we can't say that engage is the answer to that problem.
> 
> > * I don't care about keymap config since I'm american, but it seems
> > important for users to be able to type in their own language
> > * b&w is awful, we should switch to and iron out detourious for release
> 
> Yes, that's something we should do as soon as possible. As a side
> question, what is the status of that theme for elementary ? Because it
> would make sense to also do the switch for elementary at some point.
> 
> > * Improved connman support is a big sticking point for me. I strongly
> > believe that if the module does not improve now while it is actually a
> > blocker for release, it never will. To this end, it's missing 3 big
> > features that I can see people using: hidden network support, static ip
> > setting, and enterprise encryption. It's likely that this is not actually a
> > 6 month project as you have implied.
> 
> Well, I have been using connman module since now one year and there is
> only one place in the world where I would have liked to have a UI to
> set static IP and a VPN... I am sure that's raster is in that place
> most of the time like some of our user base :-) So not a strong
> requirement from my point of view, but maybe some people at Samsung
> could take over that item as of course you are all using E17 !
> 
> >> EXTRA DISCUSSIONS
> >>    * e_widgets is amazingly boring an

Re: [E-devel] RFC: E17 Release

[The Rasterman]

On Fri, 28 Oct 2011 18:24:56 +0200 Nicolas Aguirre 
said:

> Hi,
> 
> 2011/10/28 Gustavo Sverzut Barbieri :
> > Hello all,
> >
> > I'm writing this mail so it's unified and everyone can opine without
> > being in one place at one time (IRC/#edevelop).
> >
> > Recently I've talked to people and while I tried to express it at IRC,
> > raster just got pissed and left. Later people would join and agree
> > with me... so while I'm looking like a jerk I guess I'm not alone in
> > there. I'll try to be as clear and short as possible.
> >
> > WHY RELEASE?
> >   1. to clarify we know some snapshot is usable. This will get us in
> > more distributions by default.
> >   2. to remove that stupid karma over the 17 number if e. Will help
> > people that do not track us closely to know we're reasonable serious.
> >   3. we can start to bring in new technology without delaying it even
> > further (ie: elm and scripting language - js/elev8)
> >
> > WHY NOT RELEASE?
> >   1. there are both bugs (eg: efm)
> >   2. missing features (xrandr, taskbar, ...)
> 
> taskbar ? engage is much better than taskbar, why it's not in e17 ?

it requires compositing to work vaguely decently.

> >
> > EXTRA DISCUSSIONS
> >   * e_widgets is amazingly boring and gets in the way, people expect
> > something like Elementary to help them. Or even better, for rarely
> > used features like a mixer control dialog, xrandr dialog, connection
> > manager configuration these things could be done with a high level
> > language such as elev8. Thus lots of people would be motivated to help
> > get more features in. But introducing this now would delay e17 even
> > more, thus a no go.  (Personal note I'm highly demotivated to hack e17
> > due this exact reason. Doing a mixer dialog in e_widget is like few
> > days, in elev8 it should take me few hours -- easier to find than few
> > days)
> >
> >   * we'd like to have an officially supported and widely accepted
> > high level language. While I've created and maintained Python, seems
> > it's hatted  and going nowhere. So if it's Python, Lua or JS it
> > doesn't matter, but we need one for most boring things like
> > configuration dialogs and non-critical paths... (READ: I don't want it
> > to be in composite manager, eborder, etc -- tho I'm open to have them
> > in gadcon)
> 
> I'm not completly convinced by scripting language, but i would like to
> see more code using it, to use it myself, who know's i could fallen in
> love for javascript ...
> 
> >
> >
> > AFTER RELEASE: I propose time-based releases, every 3 months we cook a
> > snap and put it out. Seems to work well for everyone out there, can't
> > see why it wouldn't work. IMO we can't have feature based snaps
> > because we don't have enough manpower to do this promises.
> > Longer release cycles are problematic as "wait my nice feature to get
> > in, it's one more week! Otherwise I'll have to wait 6+ months to get
> > it in!" and then this repeats forever as we see now.
> >
> 
> Snap every 3 month is doable IMO. And as long as elementary is not
> released, we can't  release e based on it ...
> 
> 
> >
> > BUT USERS WILL COMPLAIN ABOUT MISSING FEATURES: common argument for
> > xrandr, keyboard languages, taskbar. Users will complain, period.
> > We'll never be able to cope with minimum features, as this changes
> > from person to person. Moreover, the more we wait, the more we have to
> > do. Right now all other desktops implement the new systray and
> > application menu protocols, really soon this will be "a bare minimum"
> > for some users. There is proper PulseAudio mixer. Proper
> > ConnMan/NetworkManager. Soon we'll have the user-session and seat
> > management that GNOME is doing with systemd... This list is lways
> > growing. But we're short on human resources. Having a release and
> > getting Elev8 into E would help bringing more people to help.
> >
> > MY PROPOSAL: just fix the remaining efm bugs and other outstanding
> > crashes and do a release as is. Remove the e17 karma and get back to
> > normal life, get e18, e19... and things go into them as fast as we
> > can.
> 
> I totally agree with you.
> 
> >
> >
> >
> > --
> > Gustavo Sverzut Barbieri
> > http://profusion.mobi embedded systems
> > --
> > MSN: barbi...@gmail.com
> > Skype: gsbarbieri
> > Mobile: +55 (19) 9225-2202
> >
> > --
> > The demand for IT networking professionals continues to grow, and the
> > demand for specialized networking skills is growing even more rapidly.
> > Take a complimentary Learning@Cisco Self-Assessment and learn
> > about Cisco certifications, training, and career opportunities.
> > http://p.sf.net/sfu/cisco-dev2dev
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> 
> 
> 
> -- 
> Nicolas 

Re: [E-devel] How can I change behaviour when double-clicking a window's title?

[The Rasterman]

On Sat, 29 Oct 2011 00:21:56 +0200 Tom Hacohen  said:

> Hey,
> 
> Someone from the Israeli community asked me about it, and tbh, I have no
> idea how to do it. Gustavo said at IRC that it's possible through the
> usage of enlightenment_remote, is it?
> 
> How can I make it happen? He wants to change "shaded" to
> "maximize/unmaximize.".

singal bindings. no gui for it though. :)

> Btw, on an unrelated note, it should probably not be too hard to make it
> part of the "Mouse bindings" menu, just need to support double clicking
> as bindings...
> 
> --
> Tom.
> 
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn 
> about Cisco certifications, training, and career opportunities. 
> http://p.sf.net/sfu/cisco-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


--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] How can I change behaviour when double-clicking a window's title?

[P Purkayastha]

On Saturday, October 29, 2011 6:21:56 AM UTC+8, Tom Hacohen wrote:
>
> Hey,
>
> Someone from the Israeli community asked me about it, and tbh, I have no
> idea how to do it. Gustavo said at IRC that it's possible through the
> usage of enlightenment_remote, is it?

It used to be possible via enlightenment_remote 3 years ago. Now it is not 
possible. There is no GUI to change this.

How can I make it happen? He wants to change "shaded" to
> "maximize/unmaximize.".
>
> It is part of "Signal bindings", not "mouse bindings". You can hack into 
your e.cfg - unpack it using eet, modify the new file (look for signal 
bindings and then e.event.titlebar) and repack it into a new e.cfg - that's 
the only way for now.

 

> Btw, on an unrelated note, it should probably not be too hard to make it
> part of the "Mouse bindings" menu, just need to support double clicking
> as bindings...
>
> --
> Tom.
>
>
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn 
> about Cisco certifications, training, and career opportunities. 
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> enlightenment-devel mailing list
> enlighten...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] elev8 + dbus

[Gustavo Sverzut Barbieri]

On Fri, Oct 28, 2011 at 6:50 PM, Cedric BAIL  wrote:
> Hi,
>
> On Fri, Oct 28, 2011 at 3:16 PM, Gustavo Sverzut Barbieri
>  wrote:
>> Do you have plans to add DBus bindings to Elev8? Particularly
>> interested in ObjectManager and related support to make it easy to
>> access most system services (they are being converted to this standard
>> as Glib standardizes this method).
>
> What is this ObjectManager things ? I tried to do a quick google and
> ended up with some pointer to Windows, so either Vincent was able to
> drive Glib folks to embrace the evil or I didn't find the right
> pointer...

http://davidz25.blogspot.com/2011/09/new-d-bus-features-in-glib-230.html

I'm trying to find sponsors for this in e_dbus as well. As in glib, it
should be doable with a codegen, but in elev8 it needs nothing.



>> I plan to write small tests for PulseAudio, ConnMan and BlueZ using
>> it. But there are also Tracker, MPRIS, UPower, UDisks, Telepathy and
>> others using it as well.
>
> Yeah, it will really make sense to have all of them, it will really
> start to be time consuming to maintain that. Do you have any idea how
> we could automate it ?

See above. With ObjectManager (not all services are using it YET) and
DBus introspection we could easily generate C code to get the
properties and notify of signals. If you read e_bluez and e_connman
they are basically copy & paste of each others and should be the best
users of e_dbus nowadays... (except some possible copy & paste bugs).
It is VERY boring to keep in sync with upstream api.

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

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] elev8 + dbus

[Gustavo Sverzut Barbieri]

On Fri, Oct 28, 2011 at 4:47 PM, Mike Blumenkrantz  wrote:
> On Fri, 28 Oct 2011 11:16:54 -0200
> Gustavo Sverzut Barbieri  wrote:
>
>> Hi Sanjeev,
>>
>> Do you have plans to add DBus bindings to Elev8? Particularly
>> interested in ObjectManager and related support to make it easy to
>> access most system services (they are being converted to this standard
>> as Glib standardizes this method).
>>
>> I plan to write small tests for PulseAudio, ConnMan and BlueZ using
>> it. But there are also Tracker, MPRIS, UPower, UDisks, Telepathy and
>> others using it as well.
>>
>> BR,
>>
> sigh someone should probably write an epulse module for e_dbus to manage the
> pulseaudio dbus api

with elev8 bindings we need no e_dbus_pulse or e_dbus_connman or
e_dbus_ofono or e_dbus_bluez or ... it's automatic for dynamic
languages.

That's why I mean it would be amazingly helpful. Writing a PA mixer in
JS/elev8 should take me few hours, while doing it in C will take me a
few days. Really.

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

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] How can I change behaviour when double-clicking a window's title?

[Tom Hacohen]

Hey,

Someone from the Israeli community asked me about it, and tbh, I have no
idea how to do it. Gustavo said at IRC that it's possible through the
usage of enlightenment_remote, is it?

How can I make it happen? He wants to change "shaded" to
"maximize/unmaximize.".

Btw, on an unrelated note, it should probably not be too hard to make it
part of the "Mouse bindings" menu, just need to support double clicking
as bindings...

--
Tom.

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Backlight module

[evadim]

Hello!

I have question about backlight module it don't work for me for a log time.
I look into it and found acpi paths a bit different [1] than in my system,
so I correct it and module start working. In first hunk, I think, I see typo,
but about paths I don't know what to do: Work it for somebody? May be some
old kernels had this paths? How to make module work on old & new systems?
Now I use kernel 3.* and my friends have paths like me.

Thanks!

[1] http://paste.pocoo.org/show/498694/

backlight.patch
Description: Binary data
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] elev8 + dbus

[Cedric BAIL]

Hi,

On Fri, Oct 28, 2011 at 3:16 PM, Gustavo Sverzut Barbieri
 wrote:
> Do you have plans to add DBus bindings to Elev8? Particularly
> interested in ObjectManager and related support to make it easy to
> access most system services (they are being converted to this standard
> as Glib standardizes this method).

What is this ObjectManager things ? I tried to do a quick google and
ended up with some pointer to Windows, so either Vincent was able to
drive Glib folks to embrace the evil or I didn't find the right
pointer...

> I plan to write small tests for PulseAudio, ConnMan and BlueZ using
> it. But there are also Tracker, MPRIS, UPower, UDisks, Telepathy and
> others using it as well.

Yeah, it will really make sense to have all of them, it will really
start to be time consuming to maintain that. Do you have any idea how
we could automate it ?
-- 
Cedric BAIL

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] RFC: E17 Release

[Cedric BAIL]

On Fri, Oct 28, 2011 at 9:19 PM, Mike Blumenkrantz  wrote:
> On Fri, 28 Oct 2011 11:07:45 -0200
> Gustavo Sverzut Barbieri  wrote:
>> I'm writing this mail so it's unified and everyone can opine without
>> being in one place at one time (IRC/#edevelop).
>>
>> Recently I've talked to people and while I tried to express it at IRC,
>> raster just got pissed and left. Later people would join and agree
>> with me... so while I'm looking like a jerk I guess I'm not alone in
>> there. I'll try to be as clear and short as possible.
>>
>> WHY RELEASE?
>>    1. to clarify we know some snapshot is usable. This will get us in
>> more distributions by default.
> good
>>    2. to remove that stupid karma over the 17 number if e. Will help
>> people that do not track us closely to know we're reasonable serious.
> people will probably still call it e17 even when we're on e20
>>    3. we can start to bring in new technology without delaying it even
>> further (ie: elm and scripting language - js/elev8)
> not really a valid reason to release, you can see it did wonders for gnome

http://www.phoronix.com/scan.php?page=article&item=gnome_survey_part1&num=1

I don't really see the link with what you are saying.

>> WHY NOT RELEASE?
>>    1. there are both bugs (eg: efm)
> cedric has said a number of times that he'll be working on efm after he
> finishes emotion soon, and I'll likely disable eeze mounting entirely for the
> release since libmount is not widely deployed and I was unable to get
> widespread testing until now.
>>    2. missing features (xrandr, taskbar, ...)
> * xrandr patches have been made and are on the list waiting for testing and
> review, so I'm not really sure why this is a "missing" feature.
> * New users will not be able to deal with E17 if it doesn't have a taskbar, 
> end
> of story. Engage is in SVN now, it's usable and widely used already, it can be
> merged.

No you can't ! Doesn't solve the problem for non composite use case
and as long as we don't make the compositer the only possible choice
we can't say that engage is the answer to that problem.

> * I don't care about keymap config since I'm american, but it seems important
>  for users to be able to type in their own language
> * b&w is awful, we should switch to and iron out detourious for release

Yes, that's something we should do as soon as possible. As a side
question, what is the status of that theme for elementary ? Because it
would make sense to also do the switch for elementary at some point.

> * Improved connman support is a big sticking point for me. I strongly believe
>  that if the module does not improve now while it is actually a blocker for
>  release, it never will. To this end, it's missing 3 big features that I can
>  see people using: hidden network support, static ip setting, and enterprise
>  encryption. It's likely that this is not actually a 6 month project as you
>  have implied.

Well, I have been using connman module since now one year and there is
only one place in the world where I would have liked to have a UI to
set static IP and a VPN... I am sure that's raster is in that place
most of the time like some of our user base :-) So not a strong
requirement from my point of view, but maybe some people at Samsung
could take over that item as of course you are all using E17 !

>> EXTRA DISCUSSIONS
>>    * e_widgets is amazingly boring and gets in the way, people expect
>> something like Elementary to help them. Or even better, for rarely
>> used features like a mixer control dialog, xrandr dialog, connection
>> manager configuration these things could be done with a high level
>> language such as elev8. Thus lots of people would be motivated to help
>> get more features in. But introducing this now would delay e17 even
>> more, thus a no go.  (Personal note I'm highly demotivated to hack e17
>> due this exact reason. Doing a mixer dialog in e_widget is like few
>> days, in elev8 it should take me few hours -- easier to find than few
>> days)
> No argument here, though I think it's more an issue that e_widgets lacks
> documentation. It works fine and is actually easier/faster to use than elm in 
> a
> lot of cases once you get the hang of it.

Well, I think we both are doing hugly UI, maybe we should not comment
on that part.

>>    * we'd like to have an officially supported and widely accepted
>> high level language. While I've created and maintained Python, seems
>> it's hatted  and going nowhere. So if it's Python, Lua or JS it
>> doesn't matter, but we need one for most boring things like
>> configuration dialogs and non-critical paths... (READ: I don't want it
>> to be in composite manager, eborder, etc -- tho I'm open to have them
>> in gadcon)
> This is going to be a pain for those that don't know the scripting
> language chosen, but I suppose the onslaught of progress must not be stopped.

You know what, you can code in JS like you do in C. You just need to
remove all that useless typing. So any one of us that k

Re: [E-devel] elev8 + dbus

[Sanjeev B.A.]

Hello Gustavo,

I intend to finish pending elm widgets followed by evas API support and
refactoring. It must take about a week to complete.
I had plans to work on DBus after the above.

Does this sound ok ? Kindly let me know.

Regards,
Sanjeev


On Fri, Oct 28, 2011 at 3:16 PM, Gustavo Sverzut Barbieri <
barbi...@gmail.com> wrote:

> Hi Sanjeev,
>
> Do you have plans to add DBus bindings to Elev8? Particularly
> interested in ObjectManager and related support to make it easy to
> access most system services (they are being converted to this standard
> as Glib standardizes this method).
>
> I plan to write small tests for PulseAudio, ConnMan and BlueZ using
> it. But there are also Tracker, MPRIS, UPower, UDisks, Telepathy and
> others using it as well.
>
> BR,
>
> --
> Gustavo Sverzut Barbieri
> --
> Mobile: +55 (19) 9225-2202
> Contact: http://www.gustavobarbieri.com.br/contact
>
>
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] RFC: E17 Release

[Mike Blumenkrantz]

On Fri, 28 Oct 2011 11:07:45 -0200
Gustavo Sverzut Barbieri  wrote:

> Hello all,
> 
> I'm writing this mail so it's unified and everyone can opine without
> being in one place at one time (IRC/#edevelop).
> 
> Recently I've talked to people and while I tried to express it at IRC,
> raster just got pissed and left. Later people would join and agree
> with me... so while I'm looking like a jerk I guess I'm not alone in
> there. I'll try to be as clear and short as possible.
> 
> WHY RELEASE?
>1. to clarify we know some snapshot is usable. This will get us in
> more distributions by default.
good
>2. to remove that stupid karma over the 17 number if e. Will help
> people that do not track us closely to know we're reasonable serious.
people will probably still call it e17 even when we're on e20
>3. we can start to bring in new technology without delaying it even
> further (ie: elm and scripting language - js/elev8)
not really a valid reason to release, you can see it did wonders for gnome
> 
> WHY NOT RELEASE?
>1. there are both bugs (eg: efm)
cedric has said a number of times that he'll be working on efm after he
finishes emotion soon, and I'll likely disable eeze mounting entirely for the
release since libmount is not widely deployed and I was unable to get
widespread testing until now.
>2. missing features (xrandr, taskbar, ...)
* xrandr patches have been made and are on the list waiting for testing and
review, so I'm not really sure why this is a "missing" feature.
* New users will not be able to deal with E17 if it doesn't have a taskbar, end
of story. Engage is in SVN now, it's usable and widely used already, it can be
merged.
* I don't care about keymap config since I'm american, but it seems important
  for users to be able to type in their own language
* b&w is awful, we should switch to and iron out detourious for release
* Improved connman support is a big sticking point for me. I strongly believe
  that if the module does not improve now while it is actually a blocker for
  release, it never will. To this end, it's missing 3 big features that I can
  see people using: hidden network support, static ip setting, and enterprise
  encryption. It's likely that this is not actually a 6 month project as you
  have implied.
> 
> EXTRA DISCUSSIONS
>* e_widgets is amazingly boring and gets in the way, people expect
> something like Elementary to help them. Or even better, for rarely
> used features like a mixer control dialog, xrandr dialog, connection
> manager configuration these things could be done with a high level
> language such as elev8. Thus lots of people would be motivated to help
> get more features in. But introducing this now would delay e17 even
> more, thus a no go.  (Personal note I'm highly demotivated to hack e17
> due this exact reason. Doing a mixer dialog in e_widget is like few
> days, in elev8 it should take me few hours -- easier to find than few
> days)
No argument here, though I think it's more an issue that e_widgets lacks
documentation. It works fine and is actually easier/faster to use than elm in a
lot of cases once you get the hang of it.
> 
>* we'd like to have an officially supported and widely accepted
> high level language. While I've created and maintained Python, seems
> it's hatted  and going nowhere. So if it's Python, Lua or JS it
> doesn't matter, but we need one for most boring things like
> configuration dialogs and non-critical paths... (READ: I don't want it
> to be in composite manager, eborder, etc -- tho I'm open to have them
> in gadcon)
This is going to be a pain for those that don't know the scripting
language chosen, but I suppose the onslaught of progress must not be stopped.
> 
> 
> AFTER RELEASE: I propose time-based releases, every 3 months we cook a
> snap and put it out. Seems to work well for everyone out there, can't
> see why it wouldn't work. IMO we can't have feature based snaps
> because we don't have enough manpower to do this promises.
> Longer release cycles are problematic as "wait my nice feature to get
> in, it's one more week! Otherwise I'll have to wait 6+ months to get
> it in!" and then this repeats forever as we see now.
reasonable
> 
> 
> BUT USERS WILL COMPLAIN ABOUT MISSING FEATURES: common argument for
> xrandr, keyboard languages, taskbar. Users will complain, period.
> We'll never be able to cope with minimum features, as this changes
> from person to person. Moreover, the more we wait, the more we have to
> do. Right now all other desktops implement the new systray and
> application menu protocols, really soon this will be "a bare minimum"
> for some users. There is proper PulseAudio mixer. Proper
> ConnMan/NetworkManager. Soon we'll have the user-session and seat
> management that GNOME is doing with systemd... This list is lways
> growing. But we're short on human resources. Having a release and
> getting Elev8 into E would help bringing more people to help.
If we cared about user opinions so muc

Re: [E-devel] RFC: E17 Release

[Mike Blumenkrantz]

On Fri, 28 Oct 2011 06:57:02 -0700 (PDT)
P Purkayastha  wrote:

> As an end user, I too feel e17 should get out. Nothing much has changed in 
> core e over the past year, except for dialogs, and reshuffling of menus, 
> addition of shot module, and some polish over the past 3-4 months into 
> making it work better with desktop files and with startup applications of 
> gnome, kde. There has been some nice additions like composite but that was 
> mostly done more than 1.5 years ago. Stability-wise there is not much of an 
> issue (hasn't been much of an issue for years and years since the devs eat 
> their own dog-food), except a couple of minor bugs.
False. EFM gained 2 new device backends, xsettings module was created and
merged, notifications module was merged, we now support regular image
backgrounds, comp-scale was created (not core YET), pulseaudio mixer support is
in, and there's more that isn't coming to mind immediately.

-- 
Mike Blumenkrantz
Zentific: Doctor recommended, mother approved.

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] elev8 + dbus

[Mike Blumenkrantz]

On Fri, 28 Oct 2011 11:16:54 -0200
Gustavo Sverzut Barbieri  wrote:

> Hi Sanjeev,
> 
> Do you have plans to add DBus bindings to Elev8? Particularly
> interested in ObjectManager and related support to make it easy to
> access most system services (they are being converted to this standard
> as Glib standardizes this method).
> 
> I plan to write small tests for PulseAudio, ConnMan and BlueZ using
> it. But there are also Tracker, MPRIS, UPower, UDisks, Telepathy and
> others using it as well.
> 
> BR,
> 
sigh someone should probably write an epulse module for e_dbus to manage the
pulseaudio dbus api

-- 
Mike Blumenkrantz
Zentific: Doctor recommended, mother approved.

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] RFC: E17 Release

[Nicolas Aguirre]

Hi,

2011/10/28 Gustavo Sverzut Barbieri :
> Hello all,
>
> I'm writing this mail so it's unified and everyone can opine without
> being in one place at one time (IRC/#edevelop).
>
> Recently I've talked to people and while I tried to express it at IRC,
> raster just got pissed and left. Later people would join and agree
> with me... so while I'm looking like a jerk I guess I'm not alone in
> there. I'll try to be as clear and short as possible.
>
> WHY RELEASE?
>   1. to clarify we know some snapshot is usable. This will get us in
> more distributions by default.
>   2. to remove that stupid karma over the 17 number if e. Will help
> people that do not track us closely to know we're reasonable serious.
>   3. we can start to bring in new technology without delaying it even
> further (ie: elm and scripting language - js/elev8)
>
> WHY NOT RELEASE?
>   1. there are both bugs (eg: efm)
>   2. missing features (xrandr, taskbar, ...)

taskbar ? engage is much better than taskbar, why it's not in e17 ?

>
> EXTRA DISCUSSIONS
>   * e_widgets is amazingly boring and gets in the way, people expect
> something like Elementary to help them. Or even better, for rarely
> used features like a mixer control dialog, xrandr dialog, connection
> manager configuration these things could be done with a high level
> language such as elev8. Thus lots of people would be motivated to help
> get more features in. But introducing this now would delay e17 even
> more, thus a no go.  (Personal note I'm highly demotivated to hack e17
> due this exact reason. Doing a mixer dialog in e_widget is like few
> days, in elev8 it should take me few hours -- easier to find than few
> days)
>
>   * we'd like to have an officially supported and widely accepted
> high level language. While I've created and maintained Python, seems
> it's hatted  and going nowhere. So if it's Python, Lua or JS it
> doesn't matter, but we need one for most boring things like
> configuration dialogs and non-critical paths... (READ: I don't want it
> to be in composite manager, eborder, etc -- tho I'm open to have them
> in gadcon)

I'm not completly convinced by scripting language, but i would like to
see more code using it, to use it myself, who know's i could fallen in
love for javascript ...

>
>
> AFTER RELEASE: I propose time-based releases, every 3 months we cook a
> snap and put it out. Seems to work well for everyone out there, can't
> see why it wouldn't work. IMO we can't have feature based snaps
> because we don't have enough manpower to do this promises.
> Longer release cycles are problematic as "wait my nice feature to get
> in, it's one more week! Otherwise I'll have to wait 6+ months to get
> it in!" and then this repeats forever as we see now.
>

Snap every 3 month is doable IMO. And as long as elementary is not
released, we can't  release e based on it ...


>
> BUT USERS WILL COMPLAIN ABOUT MISSING FEATURES: common argument for
> xrandr, keyboard languages, taskbar. Users will complain, period.
> We'll never be able to cope with minimum features, as this changes
> from person to person. Moreover, the more we wait, the more we have to
> do. Right now all other desktops implement the new systray and
> application menu protocols, really soon this will be "a bare minimum"
> for some users. There is proper PulseAudio mixer. Proper
> ConnMan/NetworkManager. Soon we'll have the user-session and seat
> management that GNOME is doing with systemd... This list is lways
> growing. But we're short on human resources. Having a release and
> getting Elev8 into E would help bringing more people to help.
>
> MY PROPOSAL: just fix the remaining efm bugs and other outstanding
> crashes and do a release as is. Remove the e17 karma and get back to
> normal life, get e18, e19... and things go into them as fast as we
> can.

I totally agree with you.

>
>
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>



-- 
Nicolas Aguirre
Mail: aguirre.nico...@gmail.com
Web: http://enna.geexbox.org
Blog: http://dev.enlightenment.fr/~captainigloo/

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidl

Re: [E-devel] RFC: E17 Release

[Tom Hacohen]

On 28/10/11 15:07, Gustavo Sverzut Barbieri wrote:
> WHY RELEASE?
>1. to clarify we know some snapshot is usable. This will get us in
> more distributions by default.
>2. to remove that stupid karma over the 17 number if e. Will help
> people that do not track us closely to know we're reasonable serious.
>3. we can start to bring in new technology without delaying it even
> further (ie: elm and scripting language - js/elev8)

4. To let slow bureaucratic distros that don't include "unstable"
packages include e17...
5. Gnome3 sucks, KDE4 sucks, xfce is actually pretty decent, but
generally, many people I know are leaving the linux world because of
that, they usually tell me: "Linux no longer serves me better than the
other options." and they usually blame Gnome3 for that. I agree with
them, Gnome3 is what made me move to e17 full time (both at work and at
home).

> WHY NOT RELEASE?
>1. there are both bugs (eg: efm)

As I said many times before, yeah, efm is nice and should be fixed, but
we should add better support for using other file managers, which are
better and more feature rich.

>2. missing features (xrandr, taskbar, ...)

I consider those as extras, really. But language support is pretty painful,
it's hard for Latin users to understand, but it's really needed. :)

> EXTRA DISCUSSIONS
>* e_widgets is amazingly boring and gets in the way, people expect
> something like Elementary to help them. Or even better, for rarely
> used features like a mixer control dialog, xrandr dialog, connection
> manager configuration these things could be done with a high level
> language such as elev8. Thus lots of people would be motivated to help
> get more features in. But introducing this now would delay e17 even
> more, thus a no go.  (Personal note I'm highly demotivated to hack e17
> due this exact reason. Doing a mixer dialog in e_widget is like few
> days, in elev8 it should take me few hours -- easier to find than few
> days)

Yeah, I agree, lets kick e17 out the release door and get on jigging
with some real toolkits ;P
> 
>* we'd like to have an officially supported and widely accepted
> high level language. While I've created and maintained Python, seems
> it's hatted  and going nowhere. So if it's Python, Lua or JS it
> doesn't matter, but we need one for most boring things like
> configuration dialogs and non-critical paths... (READ: I don't want it
> to be in composite manager, eborder, etc -- tho I'm open to have them
> in gadcon)
> 

I actually like Python, better than most other high level languages I
guess, but heck, I also vote for JS. :)
> 
> AFTER RELEASE: I propose time-based releases, every 3 months we cook a
> snap and put it out. Seems to work well for everyone out there, can't
> see why it wouldn't work. IMO we can't have feature based snaps
> because we don't have enough manpower to do this promises.
> Longer release cycles are problematic as "wait my nice feature to get
> in, it's one more week! Otherwise I'll have to wait 6+ months to get
> it in!" and then this repeats forever as we see now.

Lets make it 3-6, i.e per release, tbh, I'm a real believer in release
early-release often, but I guess that only works for some of the people.
There's no reason why not release a minor version a week or two after a
big bug was fixed.

I guess we'll call e17 enlightenment version 17.0.0, just because it'll
feel more natural to most people (e17 1.0 and then e18 1.0 would be too
weird, same goes for e17 2.0) or, we can "rename" it back to e and make
it a 1.0, but that's really something to think about, PR-wise. I vote
for e 17.0.0. If that's the case, there's no reason why not to release a
0.0.1 version every couple of weeks, and only 0.1.0 version every couple
of months 3-6.

> 
> 
> BUT USERS WILL COMPLAIN ABOUT MISSING FEATURES: common argument for
> xrandr, keyboard languages, taskbar. Users will complain, period.

xrandr: that can be set and forgotten, or you can use a 3rd party app,
for taskbar, we have engage, yeah not perfect for everyone, but it does
the trick (I use it as an old-school taskbar) as for languages: as I
stated above, I really think it's a top priority. I don't care as much
for myself, as I just added a hackish script that calls setvxkbmap...

> This list is lways
> growing. But we're short on human resources. Having a release and
> getting Elev8 into E would help bringing more people to help.
> 
> MY PROPOSAL: just fix the remaining efm bugs and other outstanding
> crashes and do a release as is. Remove the e17 karma and get back to
> normal life, get e18, e19... and things go into them as fast as we
> can.

Yeah, I agree.

-
Tom.

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and ca

Re: [E-devel] RFC: E17 Release

[P Purkayastha]

On Friday, October 28, 2011 10:24:07 PM UTC+8, Cedric BAIL wrote:
>
> Hi,
>
> On Fri, Oct 28, 2011 at 3:07 PM, Gustavo Sverzut Barbieri
>  wrote:
> > I'm writing this mail so it's unified and everyone can opine without
> > being in one place at one time (IRC/#edevelop).
> >
> > Recently I've talked to people and while I tried to express it at IRC,
> > raster just got pissed and left. Later people would join and agree
> > with me... so while I'm looking like a jerk I guess I'm not alone in
> > there. I'll try to be as clear and short as possible.
> >
> > WHY RELEASE?
> >   1. to clarify we know some snapshot is usable. This will get us in
> > more distributions by default.
> >   2. to remove that stupid karma over the 17 number if e. Will help
> > people that do not track us closely to know we're reasonable serious.
> >   3. we can start to bring in new technology without delaying it even
> > further (ie: elm and scripting language - js/elev8)
> >
> > WHY NOT RELEASE?
> >   1. there are both bugs (eg: efm)
>
> I will be working on efm after I am done with emotion, it's the top
> priority item for me.
>
> >   2. missing features (xrandr, taskbar, ...)
> >
> > EXTRA DISCUSSIONS
> >   * e_widgets is amazingly boring and gets in the way, people expect
> > something like Elementary to help them. Or even better, for rarely
> > used features like a mixer control dialog, xrandr dialog, connection
> > manager configuration these things could be done with a high level
> > language such as elev8. Thus lots of people would be motivated to help
> > get more features in. But introducing this now would delay e17 even
> > more, thus a no go.  (Personal note I'm highly demotivated to hack e17
> > due this exact reason. Doing a mixer dialog in e_widget is like few
> > days, in elev8 it should take me few hours -- easier to find than few
> > days)
> >
> >   * we'd like to have an officially supported and widely accepted
> > high level language. While I've created and maintained Python, seems
> > it's hatted  and going nowhere. So if it's Python, Lua or JS it
> > doesn't matter, but we need one for most boring things like
> > configuration dialogs and non-critical paths... (READ: I don't want it
> > to be in composite manager, eborder, etc -- tho I'm open to have them
> > in gadcon)
> >
> >
> > AFTER RELEASE: I propose time-based releases, every 3 months we cook a
> > snap and put it out. Seems to work well for everyone out there, can't
> > see why it wouldn't work. IMO we can't have feature based snaps
> > because we don't have enough manpower to do this promises.
> > Longer release cycles are problematic as "wait my nice feature to get
> > in, it's one more week! Otherwise I'll have to wait 6+ months to get
> > it in!" and then this repeats forever as we see now.
>
> I like the idea of time based release. 3 months will maybe be hard to
> match, but we should definitly go over 6 months.
>
> > BUT USERS WILL COMPLAIN ABOUT MISSING FEATURES: common argument for
> > xrandr, keyboard languages, taskbar. Users will complain, period.
> > We'll never be able to cope with minimum features, as this changes
> > from person to person. Moreover, the more we wait, the more we have to
> > do. Right now all other desktops implement the new systray and
> > application menu protocols, really soon this will be "a bare minimum"
> > for some users. There is proper PulseAudio mixer. Proper
> > ConnMan/NetworkManager. Soon we'll have the user-session and seat
> > management that GNOME is doing with systemd... This list is lways
> > growing. But we're short on human resources. Having a release and
> > getting Elev8 into E would help bringing more people to help.
>
> User always complain, that's the annoyance with them. When you don't
> release they complain, when you release they complain, when you do
> what they asked...


Why you complain? We wanna moaar feature, less complain. Can we have edje 
support javascript? Please?  ;)


 

> > MY PROPOSAL: just fix the remaining efm bugs and other outstanding
> > crashes and do a release as is. Remove the e17 karma and get back to
> > normal life, get e18, e19... and things go into them as fast as we
> > can.
>
> Well, I would have maybe say we should do an alpha at the same time as
> we do the 1.1, so we get developper to try it and maybe help. We do
> publish what is lacking from this alpha release, but alpha is just to
> actually say : "Hey developpers, here is what we have done, try it and
> patch it before it really goes out !". At least that's my point of
> view on alpha.
> -- 
> Cedric BAIL
>
>
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn 
> about Cisco certifications, training, and career opportunities. 
> http://p.sf.net/sfu/cisco-dev2dev
> 

Re: [E-devel] [E-Devel][Patch] Evas GL Color Format Enum change (and ElmGLview changes accordingly)

[Sung W. Park]

wow, that was the fastest review/commit thus far! ;)  thanks!!

On Fri, Oct 28, 2011 at 8:08 PM, Carsten Haitzler wrote:

> On Fri, 28 Oct 2011 14:10:14 +0900 "Sung W. Park" 
> said:
>
> this one is in svn! approved. good! thanks muchly! :)
>
> > Hi all,
> >
> > I'm submitting a patch that changes the color format for Evas GL.
> >
> > When I first wrote Evas_GL, I just had EVAS_GL_RGB_8 and EVAS_GL_RGBA_8
> and
> > etc but it was misleading for some people.  It was more of a filler since
> > I couldn't decide on
> > a name.  I'm finally changing it to make it more clear.
> >
> > typedef enum _Evas_GL_Color_Format
> > {
> > EVAS_GL_RGB_888 = 0,  // 8 bits per channel
> > EVAS_GL_RGBA_ = 1
> > } Evas_GL_Color_Format;
> >
> > typedef enum _Evas_GL_Depth_Bits
> > {
> > EVAS_GL_DEPTH_NONE   = 0,
> > EVAS_GL_DEPTH_BIT_8  = 1,
> > EVAS_GL_DEPTH_BIT_16 = 2,
> > EVAS_GL_DEPTH_BIT_24 = 3,
> > EVAS_GL_DEPTH_BIT_32 = 4,
> > } Evas_GL_Depth_Bits;
> >
> > typedef enum _Evas_GL_Stencil_Bits
> > {
> > EVAS_GL_STENCIL_NONE   = 0,
> > EVAS_GL_STENCIL_BIT_1  = 1,
> > EVAS_GL_STENCIL_BIT_2  = 2,
> > EVAS_GL_STENCIL_BIT_4  = 3,
> > EVAS_GL_STENCIL_BIT_8  = 4,
> > EVAS_GL_STENCIL_BIT_16 = 5,
> > } Evas_GL_Stencil_Bits;
> >
> > This will deal with backward compatibility issues as long as we keep the
> > ordering and the number same.
> >
> > I'm also including an Elmentary patch for elm_glview.c that changes the
> format
> > accordingly.
> >
> > Two patches:
> >evas_gl_format_change.path// For Evas
> >elmglview_evas_gl_format_change.patch   // For Elementary
> >
> >
> > Thanks a bunch.
> >
> > cheers,
> > Sung
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] problem with Eina and pthread.h (to fix before 1.1 release)

[Vincent Torri]

On Fri, 28 Oct 2011, Cedric BAIL wrote:

> On Fri, Oct 28, 2011 at 2:13 PM, Youness Alaoui
>  wrote:
>> I agree with vincent, and I think that there shouldn't be a "define it
>> before including eina.h" implicit rule.. while it's not so bad, and it would
>> work, it's not the right way to do it.
>> these functions shouldn't be inlined I think, they should be a define, and
>
> Using define instead of inline has a lot issue. First it doesn't let
> the compiler when it's better or not to inline, it will always inline.
> Second it doesn't do any type checking so you can break stuff much
> more easily. And generally inline is much more easy to read than
> define.
>
>> for the posix functions, they are way too big to be inline, they would
>> dramatically increase the generated code, especially if you lock/unlock
>> everywhere.
>
> I actually don't understand what point your are trying to make here.
>
>> As for performance, give us hard numbers! I don't think it would
>> affect performance for such function calls. So in my opinion, make them
>> defines, and have the posix versions as actual functions that the defines
>> call (so for non posix with smaller functions, you don't need an actual
>> call).
>
> What does matter is call to small function, because the overhead of
> setting up the stack, saving register, jumping to the actual function
> to call and then coming by restoring register and the stack does
> introduce a cost. Something you will not see on your high end laptop,
> but on embedded device. And the inline function are function that are
> typically in the hot path of our stack, so function call really do
> matter. And moving to #define would not solve the issue Vincent is
> pointing as far as I understand it.

indeed. So, with the argument of Jorge, there are 2 problems.

Vincent

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] RFC: E17 Release

[Cedric BAIL]

Hi,

On Fri, Oct 28, 2011 at 3:07 PM, Gustavo Sverzut Barbieri
 wrote:
> I'm writing this mail so it's unified and everyone can opine without
> being in one place at one time (IRC/#edevelop).
>
> Recently I've talked to people and while I tried to express it at IRC,
> raster just got pissed and left. Later people would join and agree
> with me... so while I'm looking like a jerk I guess I'm not alone in
> there. I'll try to be as clear and short as possible.
>
> WHY RELEASE?
>   1. to clarify we know some snapshot is usable. This will get us in
> more distributions by default.
>   2. to remove that stupid karma over the 17 number if e. Will help
> people that do not track us closely to know we're reasonable serious.
>   3. we can start to bring in new technology without delaying it even
> further (ie: elm and scripting language - js/elev8)
>
> WHY NOT RELEASE?
>   1. there are both bugs (eg: efm)

I will be working on efm after I am done with emotion, it's the top
priority item for me.

>   2. missing features (xrandr, taskbar, ...)
>
> EXTRA DISCUSSIONS
>   * e_widgets is amazingly boring and gets in the way, people expect
> something like Elementary to help them. Or even better, for rarely
> used features like a mixer control dialog, xrandr dialog, connection
> manager configuration these things could be done with a high level
> language such as elev8. Thus lots of people would be motivated to help
> get more features in. But introducing this now would delay e17 even
> more, thus a no go.  (Personal note I'm highly demotivated to hack e17
> due this exact reason. Doing a mixer dialog in e_widget is like few
> days, in elev8 it should take me few hours -- easier to find than few
> days)
>
>   * we'd like to have an officially supported and widely accepted
> high level language. While I've created and maintained Python, seems
> it's hatted  and going nowhere. So if it's Python, Lua or JS it
> doesn't matter, but we need one for most boring things like
> configuration dialogs and non-critical paths... (READ: I don't want it
> to be in composite manager, eborder, etc -- tho I'm open to have them
> in gadcon)
>
>
> AFTER RELEASE: I propose time-based releases, every 3 months we cook a
> snap and put it out. Seems to work well for everyone out there, can't
> see why it wouldn't work. IMO we can't have feature based snaps
> because we don't have enough manpower to do this promises.
> Longer release cycles are problematic as "wait my nice feature to get
> in, it's one more week! Otherwise I'll have to wait 6+ months to get
> it in!" and then this repeats forever as we see now.

I like the idea of time based release. 3 months will maybe be hard to
match, but we should definitly go over 6 months.

> BUT USERS WILL COMPLAIN ABOUT MISSING FEATURES: common argument for
> xrandr, keyboard languages, taskbar. Users will complain, period.
> We'll never be able to cope with minimum features, as this changes
> from person to person. Moreover, the more we wait, the more we have to
> do. Right now all other desktops implement the new systray and
> application menu protocols, really soon this will be "a bare minimum"
> for some users. There is proper PulseAudio mixer. Proper
> ConnMan/NetworkManager. Soon we'll have the user-session and seat
> management that GNOME is doing with systemd... This list is lways
> growing. But we're short on human resources. Having a release and
> getting Elev8 into E would help bringing more people to help.

User always complain, that's the annoyance with them. When you don't
release they complain, when you release they complain, when you do
what they asked...

> MY PROPOSAL: just fix the remaining efm bugs and other outstanding
> crashes and do a release as is. Remove the e17 karma and get back to
> normal life, get e18, e19... and things go into them as fast as we
> can.

Well, I would have maybe say we should do an alpha at the same time as
we do the 1.1, so we get developper to try it and maybe help. We do
publish what is lacking from this alpha release, but alpha is just to
actually say : "Hey developpers, here is what we have done, try it and
patch it before it really goes out !". At least that's my point of
view on alpha.
-- 
Cedric BAIL

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] problem with Eina and pthread.h (to fix before 1.1 release)

[Cedric BAIL]

On Fri, Oct 28, 2011 at 2:13 PM, Youness Alaoui
 wrote:
> I agree with vincent, and I think that there shouldn't be a "define it
> before including eina.h" implicit rule.. while it's not so bad, and it would
> work, it's not the right way to do it.
> these functions shouldn't be inlined I think, they should be a define, and

Using define instead of inline has a lot issue. First it doesn't let
the compiler when it's better or not to inline, it will always inline.
Second it doesn't do any type checking so you can break stuff much
more easily. And generally inline is much more easy to read than
define.

> for the posix functions, they are way too big to be inline, they would
> dramatically increase the generated code, especially if you lock/unlock
> everywhere.

I actually don't understand what point your are trying to make here.

> As for performance, give us hard numbers! I don't think it would
> affect performance for such function calls. So in my opinion, make them
> defines, and have the posix versions as actual functions that the defines
> call (so for non posix with smaller functions, you don't need an actual
> call).

What does matter is call to small function, because the overhead of
setting up the stack, saving register, jumping to the actual function
to call and then coming by restoring register and the stack does
introduce a cost. Something you will not see on your high end laptop,
but on embedded device. And the inline function are function that are
typically in the hot path of our stack, so function call really do
matter. And moving to #define would not solve the issue Vincent is
pointing as far as I understand it.

> On Wed, Oct 26, 2011 at 8:29 AM, Cedric BAIL  wrote:
>
>> On Wed, Oct 26, 2011 at 1:48 PM, Vincent Torri 
>> wrote:
>> > On Wed, 26 Oct 2011, Cedric BAIL wrote:
>> >> On Wed, Oct 26, 2011 at 11:13 AM, Vincent Torri 
>> wrote:
>> >>> On Wed, 26 Oct 2011, Cedric BAIL wrote:
>>  On Wed, Oct 26, 2011 at 10:55 AM, Vincent Torri 
>> wrote:
>> > Eina includes eina_inline_lock_posix.h on something else than
>> Windows,
>> > hence pthread.h. _GNU_SOURCE is not defined.
>> >
>> > Suppose now that a user of Eina does this:
>> >
>> > #include 
>> > #include 
>> >
>> > The user will not have the possibility to features available with
>> > _GNU_SOURCE (like CPU_SET for example. I have that problem with
>> Enesim),
>> > except by defining it just before including Eina.h. Which is not the
>> best
>> > solution, I think.
>> >
>> > The problem, here, is that lock stuff is only inlined functions. The
>> > problem will be solved if they are in a source file. Maybe at the
>> > beginning, having these functions inlined was interesting because
>> they
>> > were short. I'm not sure that keeping them inlined is really useful,
>> now.
>> 
>>  As from a performance point of view, it really matter to have them
>>  inlined or not. Function call does cost.
>> >>>
>> >>> I know that, but i would like to have numbers, here, to verify it's
>> worth
>> >>> having them inlined. Note that I'm talking about the posix part, not
>> the
>> >>> 'void' or windows part.
>> >>>
>> >>> If your argument is : "no numbers are needed, it's faster", then why
>> not
>> >>> defining all the functions inlined ?
>> >>
>> >> I don't have access at the moment on machine where that does matter.
>> >> But to put stuff into perspective, Eina_Magic check could cost around
>> >> 10% of your time and it's just a function call with an if inside, much
>> >> simpler that taking a lock. So I don't have number, but it's just way
>> >> better to avoid the 10s instructions that are needed to do a function
>> >> call.
>> >>   And why not inlining everything,
>> >
>> > that was a sarcasm...
>> >
>> >> that why we use static inline
>> >> instead of a macro, gcc can choose to inline the function or not
>> >> depending on all the cost implied by the function call. And we don't
>> >> put all function inlined, because that would just increase the binary
>> >> size and invalidate cache to much. So it is only a solution for very
>> >> small function called very often.
>> >
>> > Look at the function eina_lock_take() in the posix file : 67 lines (with
>> > the defines). Do you call that a small function ? And I perfectly
>> remember
>> > you telling to use **static** inline to force gcc to inline the function.
>> > Now you're saying that gcc will sometimes inline it, sometimes not ?
>> > You're contradicting yourself.
>>
>> No I am not, the static is here to prevent a clash between symbol.
>> That's all it is saying and it will never force a function to be
>> inlined. It just make it possible to the compiler to do so if it makes
>> sense. I told to put static, because inline doesn't tell anything
>> about the symbol visibility and that would be an issue.
>> --
>> Cedric BAIL
>>
>>
>> --
>> The demand fo

Re: [E-devel] RFC: E17 Release

[P Purkayastha]

As an end user, I too feel e17 should get out. Nothing much has changed in 
core e over the past year, except for dialogs, and reshuffling of menus, 
addition of shot module, and some polish over the past 3-4 months into 
making it work better with desktop files and with startup applications of 
gnome, kde. There has been some nice additions like composite but that was 
mostly done more than 1.5 years ago. Stability-wise there is not much of an 
issue (hasn't been much of an issue for years and years since the devs eat 
their own dog-food), except a couple of minor bugs.
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] RFC: E17 Release

[Boris Faure]

> WHY RELEASE?
>   1. to clarify we know some snapshot is usable. This will get us in
> more distributions by default.
>   2. to remove that stupid karma over the 17 number if e. Will help
> people that do not track us closely to know we're reasonable serious.
>   3. we can start to bring in new technology without delaying it even
> further (ie: elm and scripting language - js/elev8)
>
> WHY NOT RELEASE?
>   1. there are both bugs (eg: efm)
>   2. missing features (xrandr, taskbar, ...)

Of course, we need to fix known bugs.

As stated below, people will still miss some features.


> EXTRA DISCUSSIONS
>   * e_widgets is amazingly boring and gets in the way, people expect
> something like Elementary to help them. Or even better, for rarely
> used features like a mixer control dialog, xrandr dialog, connection
> manager configuration these things could be done with a high level
> language such as elev8. Thus lots of people would be motivated to help
> get more features in. But introducing this now would delay e17 even
> more, thus a no go.  (Personal note I'm highly demotivated to hack e17
> due this exact reason. Doing a mixer dialog in e_widget is like few
> days, in elev8 it should take me few hours -- easier to find than few
> days)

I think that can be shown with the lack of motivation to work on efm
when it could be (and somehow is already) done with elementary.

>   * we'd like to have an officially supported and widely accepted
> high level language. While I've created and maintained Python, seems
> it's hatted  and going nowhere. So if it's Python, Lua or JS it
> doesn't matter, but we need one for most boring things like
> configuration dialogs and non-critical paths... (READ: I don't want it
> to be in composite manager, eborder, etc -- tho I'm open to have them
> in gadcon)

I think JS will keep getting hotter. For everything that is not in the
tight loop, it makes sense to focus mostly on code easy and fast to
write.


> AFTER RELEASE: I propose time-based releases, every 3 months we cook a
> snap and put it out. Seems to work well for everyone out there, can't
> see why it wouldn't work. IMO we can't have feature based snaps
> because we don't have enough manpower to do this promises.
> Longer release cycles are problematic as "wait my nice feature to get
> in, it's one more week! Otherwise I'll have to wait 6+ months to get
> it in!" and then this repeats forever as we see now.

Time based is ok with me.


> BUT USERS WILL COMPLAIN ABOUT MISSING FEATURES: common argument for
> xrandr, keyboard languages, taskbar. Users will complain, period.
> We'll never be able to cope with minimum features, as this changes
> from person to person. Moreover, the more we wait, the more we have to
> do. Right now all other desktops implement the new systray and
> application menu protocols, really soon this will be "a bare minimum"
> for some users. There is proper PulseAudio mixer. Proper
> ConnMan/NetworkManager. Soon we'll have the user-session and seat
> management that GNOME is doing with systemd... This list is lways
> growing. But we're short on human resources. Having a release and
> getting Elev8 into E would help bringing more people to help.

Users will always complain!
We'll be able to make a great video like the one about gnome3 release:
https://www.youtube.com/watch?v=Z-moXUALZtw

If users don't like e as it is currently, so be it!
They'll maybe try it again in 3 months and it'll be better.
Of course there will be a lot of trolls since duke nukem has been
released before e and people will be disappointed that after a decade,
e still doesn't make coffee. It will only worsen if we wait.

If we don't release asap, I fear we'll always be late to the party.

> MY PROPOSAL: just fix the remaining efm bugs and other outstanding
> crashes and do a release as is. Remove the e17 karma and get back to
> normal life, get e18, e19... and things go into them as fast as we
> can.

I do agree.

We'll add new features faster as people should be a bit more motivated
to get their code in the hands of more users with time based releases.
We all agree we need to improve our PR. It should also be easier to
write some pieces of news every 3 months about what's been done in the
last 3 months and get it on some major websites.

-- 
Boris Faure

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] elev8 + dbus

[Gustavo Sverzut Barbieri]

Hi Sanjeev,

Do you have plans to add DBus bindings to Elev8? Particularly
interested in ObjectManager and related support to make it easy to
access most system services (they are being converted to this standard
as Glib standardizes this method).

I plan to write small tests for PulseAudio, ConnMan and BlueZ using
it. But there are also Tracker, MPRIS, UPower, UDisks, Telepathy and
others using it as well.

BR,

-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (19) 9225-2202
Contact: http://www.gustavobarbieri.com.br/contact

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] RFC: E17 Release

[Gustavo Sverzut Barbieri]

Hello all,

I'm writing this mail so it's unified and everyone can opine without
being in one place at one time (IRC/#edevelop).

Recently I've talked to people and while I tried to express it at IRC,
raster just got pissed and left. Later people would join and agree
with me... so while I'm looking like a jerk I guess I'm not alone in
there. I'll try to be as clear and short as possible.

WHY RELEASE?
   1. to clarify we know some snapshot is usable. This will get us in
more distributions by default.
   2. to remove that stupid karma over the 17 number if e. Will help
people that do not track us closely to know we're reasonable serious.
   3. we can start to bring in new technology without delaying it even
further (ie: elm and scripting language - js/elev8)

WHY NOT RELEASE?
   1. there are both bugs (eg: efm)
   2. missing features (xrandr, taskbar, ...)

EXTRA DISCUSSIONS
   * e_widgets is amazingly boring and gets in the way, people expect
something like Elementary to help them. Or even better, for rarely
used features like a mixer control dialog, xrandr dialog, connection
manager configuration these things could be done with a high level
language such as elev8. Thus lots of people would be motivated to help
get more features in. But introducing this now would delay e17 even
more, thus a no go.  (Personal note I'm highly demotivated to hack e17
due this exact reason. Doing a mixer dialog in e_widget is like few
days, in elev8 it should take me few hours -- easier to find than few
days)

   * we'd like to have an officially supported and widely accepted
high level language. While I've created and maintained Python, seems
it's hatted  and going nowhere. So if it's Python, Lua or JS it
doesn't matter, but we need one for most boring things like
configuration dialogs and non-critical paths... (READ: I don't want it
to be in composite manager, eborder, etc -- tho I'm open to have them
in gadcon)


AFTER RELEASE: I propose time-based releases, every 3 months we cook a
snap and put it out. Seems to work well for everyone out there, can't
see why it wouldn't work. IMO we can't have feature based snaps
because we don't have enough manpower to do this promises.
Longer release cycles are problematic as "wait my nice feature to get
in, it's one more week! Otherwise I'll have to wait 6+ months to get
it in!" and then this repeats forever as we see now.


BUT USERS WILL COMPLAIN ABOUT MISSING FEATURES: common argument for
xrandr, keyboard languages, taskbar. Users will complain, period.
We'll never be able to cope with minimum features, as this changes
from person to person. Moreover, the more we wait, the more we have to
do. Right now all other desktops implement the new systray and
application menu protocols, really soon this will be "a bare minimum"
for some users. There is proper PulseAudio mixer. Proper
ConnMan/NetworkManager. Soon we'll have the user-session and seat
management that GNOME is doing with systemd... This list is lways
growing. But we're short on human resources. Having a release and
getting Elev8 into E would help bringing more people to help.

MY PROPOSAL: just fix the remaining efm bugs and other outstanding
crashes and do a release as is. Remove the e17 karma and get back to
normal life, get e18, e19... and things go into them as fast as we
can.



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

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Commit access request for ecore and elementary

[Gustavo Sverzut Barbieri]

On Fri, Oct 28, 2011 at 9:55 AM, Tom Hacohen  wrote:
> On 28/10/11 13:37, Carsten Haitzler (The Rasterman) wrote:
>> well for me it's a +1 because the quality is there ant it saves
>> 1. me having to review things BEFORE they go in all the time
>> 2. saves me even having to do the whole "apply patch, commit with changelog
>> etc." work
>
> I know it sounds like a troll, but I really mean it and will say it anyway:
> Git supports sending emails and applying them right off the command
> line, with git this could have been a simple "Ok, his change is not
> drastic and I trust him enough, 'git am'". Without the hassle of writing
> a commit log, applying several patches and etc.

A friendly reminder that I'm maintaining svn-git-am.py with great help
from Lucas De Marchi it seems stable and complete:

http://barbieri-playground.googlecode.com/svn/python/svn-git-am.py

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

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Commit Access

[Gustavo Sverzut Barbieri]

On Fri, Oct 28, 2011 at 7:56 AM, Mike Blumenkrantz  wrote:
>
> Hi.
>
> Before I begin, know that I am not thinking of any one person with this email,
> nor am I thinking of anyone at all. This is a general email which I am writing
> based on my own thoughts after having seen the recent flood of new developers
> (which is great!).
> Please read it as such and do not read farther into it.
>
> **
>
> SVN commit access for developers in EFL is not a right, it is a privilege. If
> you work hard, prove that you are willing to put in the time and effort to 
> make
> your code stand out, and own up to your mistakes when you make them (and we
> all do), you get commit access. We have no further policy about this, and I
> think this laid back atmosphere is one of our greatest strengths.
>
> Because of this, however, we have no precedent for informing new developers of
> the "right time" to consider obtaining commit access, nor do we tell them the
> basic rules which come with commit access after we give it out. I hope to do
> both of those things here.
>
>
> * WHEN IS THE RIGHT TIME TO ASK FOR COMMIT ACCESS? *
> The given answer is "when you feel like you've done enough to deserve it." 
> This
> is ambiguous, so I'll try to clear it up. Here are points to consider:
>
> ** You are active on enlightenment-devel, staying current with active
>   discussions
> ** You are subscribed to enlightenment-svn
> *** You read current commit emails, review the commits, and sometimes point 
> out
>    bugs or areas which could be fixed
> ** You submit patches of significant value over a period of months
> *** Your patches RARELY require any editing or revision
> ** You have an area in EFL where you could be called an expert
> *** You know the other developers who work in this area or related areas
> *** You review patches submitted to enlightenment-devel related to your area 
> of
>    expertise
> ** You are regularly in #edevelop * (this really is a requirement 
> nowadays)
>
> If most or all of the above statements apply to you, then you should probably
> be getting commit access. If not, consider whether you actually need it;
> remember that if you are a committer, YOU ARE RESPONSIBLE FOR ALL CODE WHICH
> COMES INTO YOUR INBOX. This means patches, commits, everything. If someone
> commits broken code to something that you own or manage, it's YOUR fault if
> someone else gets a broken system. If there are patches waiting to be reviewed
> for something you work on and you don't review them, THEY WILL NOT GET
> COMMITTED.
>
> This brings me to a very relevant point: over the past month(s) I have seen a
> lot of complaints that patch reviewing on enlightenment-devel is slow. The
> reason why it's slow is because people who have asked for commit access are
> either busy or lazy! Usually it's the former, in which case there is nothing 
> to
> do but wait. When developers are being lazy, the best thing to do is ask in
> #edevelop if someone can review your patch. In fact, this is ALWAYS the first
> thing that you should do before submitting a patch. If you get it 
> pre-reviewed,
> you have just reduced the time it will sit on enlightenment-devel gathering
> dust before raster gets to it.
>
> 
>
> * WHAT DOES HAVING COMMIT ACCESS MEAN? *
> When you are given commit access, this means you are considered responsible
> enough to make your own decisions. You should always attempt to observe the
> following rules, though at times you will need to break them:
>
> ** Do not bug raster about every commit you want to make. Seriously. I realize
>   the first few commits can be scary and require hand-holding, but you can
>   always come to papa discomfitor who has lots of free time to kill.
> ** Managing vs Contributing. If you are the SOLE primary committer for a
>   component, and people come to you when there are issues with it, then you
>   are managing that component. Otherwise, you are contributing. Take this into
>   account for your info.txt file to avoid confusion.
> ** If you are contributing to a component that has a manager, YOU NEED TO TALK
>   TO THEM BEFORE MAKING ANY LARGE CHANGES! As an example, everyone knows that
>   Tom Hacohen MANAGES textblock, so I would go to him if I wanted to make
>   everything someone typed come out backwards. He would tell me that this is
>   stupid, veto my patch, and SVN would be saved.
> ** It is your duty to review ALL code which touches your area(s) of expertise.
>   Your area(s) of expertise should be whatever you have listed in
>   Managing/Contributing in your info.txt. If you are not comfortable reviewing
>   code in an area, you should not be listing it here.
> ** Commit counts are NOT an indicator of quality, nor an avenue for mature
>   individuals to be competing on. If you make 50 commits in a day and do
>   nothing but fix format

Re: [E-devel] problem with Eina and pthread.h (to fix before 1.1 release)

[Youness Alaoui]

I agree with vincent, and I think that there shouldn't be a "define it
before including eina.h" implicit rule.. while it's not so bad, and it would
work, it's not the right way to do it.
these functions shouldn't be inlined I think, they should be a define, and
for the posix functions, they are way too big to be inline, they would
dramatically increase the generated code, especially if you lock/unlock
everywhere. As for performance, give us hard numbers! I don't think it would
affect performance for such function calls. So in my opinion, make them
defines, and have the posix versions as actual functions that the defines
call (so for non posix with smaller functions, you don't need an actual
call).

On Wed, Oct 26, 2011 at 8:29 AM, Cedric BAIL  wrote:

> On Wed, Oct 26, 2011 at 1:48 PM, Vincent Torri 
> wrote:
> > On Wed, 26 Oct 2011, Cedric BAIL wrote:
> >> On Wed, Oct 26, 2011 at 11:13 AM, Vincent Torri 
> wrote:
> >>> On Wed, 26 Oct 2011, Cedric BAIL wrote:
>  On Wed, Oct 26, 2011 at 10:55 AM, Vincent Torri 
> wrote:
> > Eina includes eina_inline_lock_posix.h on something else than
> Windows,
> > hence pthread.h. _GNU_SOURCE is not defined.
> >
> > Suppose now that a user of Eina does this:
> >
> > #include 
> > #include 
> >
> > The user will not have the possibility to features available with
> > _GNU_SOURCE (like CPU_SET for example. I have that problem with
> Enesim),
> > except by defining it just before including Eina.h. Which is not the
> best
> > solution, I think.
> >
> > The problem, here, is that lock stuff is only inlined functions. The
> > problem will be solved if they are in a source file. Maybe at the
> > beginning, having these functions inlined was interesting because
> they
> > were short. I'm not sure that keeping them inlined is really useful,
> now.
> 
>  As from a performance point of view, it really matter to have them
>  inlined or not. Function call does cost.
> >>>
> >>> I know that, but i would like to have numbers, here, to verify it's
> worth
> >>> having them inlined. Note that I'm talking about the posix part, not
> the
> >>> 'void' or windows part.
> >>>
> >>> If your argument is : "no numbers are needed, it's faster", then why
> not
> >>> defining all the functions inlined ?
> >>
> >> I don't have access at the moment on machine where that does matter.
> >> But to put stuff into perspective, Eina_Magic check could cost around
> >> 10% of your time and it's just a function call with an if inside, much
> >> simpler that taking a lock. So I don't have number, but it's just way
> >> better to avoid the 10s instructions that are needed to do a function
> >> call.
> >>   And why not inlining everything,
> >
> > that was a sarcasm...
> >
> >> that why we use static inline
> >> instead of a macro, gcc can choose to inline the function or not
> >> depending on all the cost implied by the function call. And we don't
> >> put all function inlined, because that would just increase the binary
> >> size and invalidate cache to much. So it is only a solution for very
> >> small function called very often.
> >
> > Look at the function eina_lock_take() in the posix file : 67 lines (with
> > the defines). Do you call that a small function ? And I perfectly
> remember
> > you telling to use **static** inline to force gcc to inline the function.
> > Now you're saying that gcc will sometimes inline it, sometimes not ?
> > You're contradicting yourself.
>
> No I am not, the static is here to prevent a clash between symbol.
> That's all it is saying and it will never force a function to be
> inlined. It just make it possible to the compiler to do so if it makes
> sense. I told to put static, because inline doesn't tell anything
> about the symbol visibility and that would be an issue.
> --
> Cedric BAIL
>
>
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/

[E-devel] [PATCH] Fix the bug that user cannot input key

[Jihoon Kim]

Hi, EFL developers and Vincent.

On Windows 7, there are some bugs related to key input in elementary_test.
1. alphabet and symbol characters doesn't be inputted in elementary entry.
2. When the space key is pressed, "space" string is entered in elementary
entry.

In this patch, I've tried to fix the above bugs.
It works well when I tested.

Would you please review this patch?

Index: ChangeLog
===
--- ChangeLog   (revision 64494)
+++ ChangeLog   (working copy)
@@ -307,3 +307,8 @@
 * Port ecore-con to work on systems without IPv6 support
 * Use inet_ntop instead of getnameinfo for ecore_con_client_get_ip
 * Added ecore-con unit test
+
+2011-10-28  Jihoon Kim
+
+* Ecore_Win32: fix the bug that the key doesn't input and "space" 
string is inserted when space key is pressed.
+
Index: src/lib/ecore_win32/ecore_win32.c
===
--- src/lib/ecore_win32/ecore_win32.c   (revision 64494)
+++ src/lib/ecore_win32/ecore_win32.c   (working copy)
@@ -86,10 +86,10 @@ _ecore_win32_window_procedure(HWND   window,
INF("keydown message");
_ecore_win32_event_handle_key_press(data, 1);
return 0;
- /* case WM_CHAR: */
- /*   INF("char message"); */
- /*   _ecore_win32_event_handle_key_press(data, 0); */
- /*   return 0; */
+ case WM_CHAR:
+   INF("char message");
+   _ecore_win32_event_handle_key_press(data, 0);
+   return 0;
  case WM_KEYUP:
INF("keyup message");
_ecore_win32_event_handle_key_release(data, 1);
Index: src/lib/ecore_win32/ecore_win32_event.c
===
--- src/lib/ecore_win32/ecore_win32_event.c (revision 64494)
+++ src/lib/ecore_win32/ecore_win32_event.c (working copy)
@@ -798,11 +798,6 @@ _ecore_win32_event_keystroke_get(intkey,
kc = "KP_Delete";
  }
break;
- case VK_SPACE:
-   kn = "space";
-   ks = "space";
-   kc = "space";
-   break;
  case VK_F1:
kn = "F1";
ks = "F1";
@@ -992,9 +987,9 @@ _ecore_win32_event_char_get(intkey,
strncpy(kc, "Escape", 32);
break;
  case VK_SPACE:
-   strncpy(kn, "space", 32);
-   strncpy(ks, "space", 32);
-   strncpy(kc, "space", 32);
+   strncpy(kn, " ", 32);
+   strncpy(ks, " ", 32);
+   strncpy(kc, " ", 32);
break;
  default:
/* displayable characters */

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Commit access request for ecore and elementary

[Tom Hacohen]

On 28/10/11 13:37, Carsten Haitzler (The Rasterman) wrote:
> well for me it's a +1 because the quality is there ant it saves
> 1. me having to review things BEFORE they go in all the time
> 2. saves me even having to do the whole "apply patch, commit with changelog
> etc." work

I know it sounds like a troll, but I really mean it and will say it anyway:
Git supports sending emails and applying them right off the command
line, with git this could have been a simple "Ok, his change is not
drastic and I trust him enough, 'git am'". Without the hassle of writing
a commit log, applying several patches and etc.

--
Tom.

Troll: GIT PWNS!


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] About Eyesight, poppler and mupdf

[Sachiel]

2011/10/28 David Seikel :
> On Fri, 28 Oct 2011 12:46:28 +0900 Carsten Haitzler (The Rasterman)
>  wrote:
>
>> unless we're now going to get high-framerate pdf's? :)
>
> Nooo!
>
> /me remembers that pdf stands for poor dead forests, and imagines the
> ecological damage killing trees at video frame rates would do.
>

Yeeeah... that's already happening. Welcome to 2011.

> --
> A big old stinking pile of genius that no one wants
> coz there are too many silver coated monkeys in the world.
>
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Commit acess request for ecore, edje and elementary

[The Rasterman]

On Fri, 28 Oct 2011 05:16:16 -0400 Mike Blumenkrantz  said:

> On Fri, 28 Oct 2011 09:15:14 +0900
> Jihoon Kim  wrote:
> 
> > Hello, EFL developers.
> > This is Jihoon Kim.
> > 
> > I'd like to request to get commit permission of EFL svn.
> > 
> > I am working for Samsung Electronics and in charge of cooperation of EFL and
> > input method framework.
> > I've mainly contributed patch for typing non-latin languages such as
> > Chinese, Japanese, Korean, so on in edje, elementary, e17 using Ecore_IMF.
> > 
> > In addition, I've also contributed for supporting keyboard input in some
> > elementary widget such as calendar, photocam, map, entry, so on.
> > 
> > I hope I have access permission and a chance to contribute easily in a
> > variety of field in EFL.
> > 
> > Would you please give me commit permission?
> > 
> > Thanks.
> I have the same question for you as I asked Hyoyoung: what are you working on
> these days which requires commit access? I know you have submitted some
> patches, but I only have a couple patches from you in the past couple months.
> 
> I'll go into a bit more detail in another email I'm composing, I don't mean to
> single you out here.

same reply from me too :)


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


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Commit access request for ecore and elementary

[The Rasterman]

On Fri, 28 Oct 2011 06:11:15 -0400 Mike Blumenkrantz  said:

> On Fri, 28 Oct 2011 18:32:29 +0900
> Hyoyoung Chang  wrote:
> 
> > To summarize my near future plan, I don't have anything to big commits.
> > I'm working frequent on elm. so I think it just speed up applying delay
> > time.
> > 
> > My decision points are that I've been patches to EFL. 
> > I feel that I'm enough accustomed with EFL. And I can make contribute.
> > So I ask about commit permission to ask for less applying patch times.
> > If there's need to big works (maybe a small ones), I'm not qualified.
> > 
> > Thank you.
> > 
> > -Original Message-
> > From: Mike Blumenkrantz [mailto:m...@zentific.com] 
> > Sent: Friday, October 28, 2011 6:09 PM
> > To: Enlightenment developer list
> > Cc: hyoyo...@gmail.com
> > Subject: Re: [E-devel] Commit access request for ecore and elementary
> > 
> > On Fri, 28 Oct 2011 00:38:25 +0900
> > Hyoyoung Chang  wrote:
> > 
> > > Dear all,
> > > Hello. This is Hyoyoung Chang
> > > 
> > > I write this mail to request the commit permission.
> > > Before join EFL, I was working on window manager and copy&paste on X11.
> > > 
> > > I've contribute ecore and (mostly) elementary.
> > > I'd fixed some selection bugs on ecore and modified elementary widgets.
> > > My previous works are that adding ellipsis feature to elm_label,
> > > enhancing elm_cnp_helper, bugfixing elm_genlist,
> > > and adding some functionality to elm widgets.
> > > 
> > > If I got a commit permission, I'll work on selection(a.k.a. copy&paste)
> > and
> > > elm widgets.
> > > 
> > > I got much help of efl community.
> > > I really want to say, Thanks for that.
> > > And I wish to be a member of EFL community with yours.
> > > 
> > > Thank you.
> > > 
> > > PS: I'm on irc as ihyoyoung. but first i is mute letter.
> > > 
> > >
> > 
> > --
> > > The demand for IT networking professionals continues to grow, and the
> > > demand for specialized networking skills is growing even more rapidly.
> > > Take a complimentary Learning@Cisco Self-Assessment and learn 
> > > about Cisco certifications, training, and career opportunities. 
> > > http://p.sf.net/sfu/cisco-dev2dev
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > My question is: what are you actively working on which requires svn access?
> > I
> > think you've contributed a lot, but I haven't seen many patches out of you
> > in
> > the past month. Are you working on something big which will require lots of
> > commits in the near future?
> > 
> There's no way to avoid sounding like a dick when I say this, but I feel like
> it's going to set precedent otherwise so here goes:
> 
> * I personally really appreciate all the work you do, as it has helped me out
> * Your work is always of high quality
> * You know the areas that you listed very well
> * You do not review commits
> * You do not review other patches
> * You average 1 patch sent to enlightenment-devel every 1-2 weeks
> 
> With this said, please check the suggested criteria that I have mentioned in
> my longer email. You undoubtedly know elm cnp better than anyone else at this
> point, and if you had projects which would require lots of patches being sent
> and reviewed I would be all for giving you access. Alternatively, if you were
> regularly reviewing patches/commits I would give my +1. It appears that you
> aren't doing either right now, however, so I will be -1. Please reply again
> right away if either of these things change! :)

well for me it's a +1 because the quality is there ant it saves
1. me having to review things BEFORE they go in all the time
2. saves me even having to do the whole "apply patch, commit with changelog
etc." work


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


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Adding array of simple types to an eet.

[David Seikel]

On Fri, 28 Oct 2011 20:01:09 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Fri, 28 Oct 2011 16:08:52 +1000 David Seikel 
> said:
> 
> > Here's the patch, as promised.
> 
> tick! commit it :)

That's my token commit for this year.  I got in early, and can take the
rest of the year off.

Or do the promised lua stuff eventually.

Back to being a grumpy mail bot.

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


signature.asc
Description: PGP signature
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: onefang trunk/eet/src/lib

[David Seikel]

On Fri, 28 Oct 2011 07:18:28 -0400 Mike Blumenkrantz
 wrote:

> On Fri, 28 Oct 2011 04:21:03 -0700
> "Enlightenment SVN"  wrote:
> 
> > Log:
> > A new macro to support adding arrays of basic types.

> CHANGE. LOG.

Was done already.  :-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
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

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

[WooHyun Jung]

+1 ~

(wanna hear Tom's opinion. Is there any reason that this API is not
deprecated yet?)

2011/10/28, Mike Blumenkrantz :
> On Thu, 27 Oct 2011 12:12:54 -0700
> "Enlightenment SVN"  wrote:
>
>> Log:
>> add long forgotten note for entry filters
>>
>>
>> Author:   discomfitor
>> Date: 2011-10-27 12:12:53 -0700 (Thu, 27 Oct 2011)
>> New Revision: 64446
>> Trac: http://trac.enlightenment.org/e/changeset/64446
>>
>> Modified:
>>   trunk/elementary/src/lib/Elementary.h.in
>>
>> Modified: trunk/elementary/src/lib/Elementary.h.in
>> ===
>> --- trunk/elementary/src/lib/Elementary.h.in 2011-10-27 18:59:57 UTC
>> (rev 64445) +++ trunk/elementary/src/lib/Elementary.h.in 2011-10-27
>> 19:12:53 UTC (rev 64446) @@ -11062,6 +11062,7 @@
>>  * @param entry The text to be displayed
>>  *
>>  * @deprecated Use elm_object_text_set() instead.
>> +* @note Using this function bypasses text filters
>>  */
>> EAPI void elm_entry_entry_set(Evas_Object *obj, const char
>> *entry) EINA_ARG_NONNULL(1); /**
>>
>>
>> --
>> The demand for IT networking professionals continues to grow, and the
>> demand for specialized networking skills is growing even more rapidly.
>> Take a complimentary Learning@Cisco Self-Assessment and learn
>> about Cisco certifications, training, and career opportunities.
>> http://p.sf.net/sfu/cisco-dev2dev
>> ___
>> enlightenment-svn mailing list
>> enlightenment-...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
> debated putting this on text_set() too. thoughts?
>
> --
> Mike Blumenkrantz
> Zentific: Doctor recommended, mother approved.
>
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Elementary Map Issues

[The Rasterman]

On Fri, 28 Oct 2011 17:35:10 +0900 Kim Yunhan  said:

> Yes, elm_map tried to reload itself is best solution, I think.
> But elementary can't detect internet connection.
> So if the retry logic is given, it should controlled by the application.

then the application will have to control retries per tile - that's a bit much
to ask. i think there should be some default retry logic. the default retry
logic, if there is NO connection will fail instantly per try. good retry logic
can detect this and pass on the "there is a serious problem" callback to the
app.

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


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: onefang trunk/eet/src/lib

[Mike Blumenkrantz]

On Fri, 28 Oct 2011 04:21:03 -0700
"Enlightenment SVN"  wrote:

> Log:
> A new macro to support adding arrays of basic types.
>   
> 
> Author:   onefang
> Date: 2011-10-28 04:21:03 -0700 (Fri, 28 Oct 2011)
> New Revision: 64493
> Trac: http://trac.enlightenment.org/e/changeset/64493
> 
> Modified:
>   trunk/eet/src/lib/Eet.h 
> 
> Modified: trunk/eet/src/lib/Eet.h
> ===
> --- trunk/eet/src/lib/Eet.h   2011-10-28 11:15:33 UTC (rev 64492)
> +++ trunk/eet/src/lib/Eet.h   2011-10-28 11:21:03 UTC (rev 64493)
> @@ -3104,6 +3104,35 @@
>  } while (0)
>  
>  /**
> + * Add an array of basic data elements to a data descriptor.
> + * @param edd The data descriptor to add the type to.
> + * @param struct_type The type of the struct.
> + * @param name The string name to use to encode/decode this member
> + *(must be a constant global and never change).
> + * @param member The struct member itself to be encoded.
> + * @param type The type of the member to encode.
> + *
> + * This macro lets you easily add a fixed size array of basic data
> + * types. All the parameters are the same as for
> + * EET_DATA_DESCRIPTOR_ADD_BASIC().
> + * The array must be defined with a fixed size in the declaration of the
> + * struct containing it.
> + *
> + * @since 1.5.0
> + * @ingroup Eet_Data_Group
> + */
> +#define EET_DATA_DESCRIPTOR_ADD_BASIC_ARRAY(edd, struct_type, name, member,
> type) \
> +  do
> {\
> +   struct_type
> ___ett;\
> +   eet_data_descriptor_element_add(edd, name, type,
> EET_G_ARRAY,  \
> +   (char *)(& (___ett.member))
> -  \
> +   (char *)(&
> (___ett)),  \
> +
> sizeof(___ett.member) /\
> +
> sizeof(___ett.member[0]),  \
> +   NULL,
> NULL);   \
> +} while(0)
> +
> +/**
>   * Add a fixed size array type to a data descriptor
>   * @param edd The data descriptor to add the type to.
>   * @param struct_type The type of the struct.
> 
> 
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn 
> about Cisco certifications, training, and career opportunities. 
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
CHANGE. LOG.

-- 
Mike Blumenkrantz
Zentific: Doctor recommended, mother approved.

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: jypark trunk/ecore/src/lib/ecore_evas

[Mike Blumenkrantz]

On Fri, 28 Oct 2011 04:15:33 -0700
"Enlightenment SVN"  wrote:

> Log:
> Add a new API(ecore_evas_request_geometry_get)
>   
>   The reson why I add this is for communicate with X in async mode.
>   For example, If applications call elm_win_rotation_with_resize_set API
>   when they start run and rotation mode is set.
>   ecore size doesn't changed yet, so it make elm window size to 1
>   becaues elm window's resize function use ecore_evas_geometry_get API.
>   so I add new api help upperside get info related with recently request
> geometry 
>   
> 
> Author:   jypark
> Date: 2011-10-28 04:15:33 -0700 (Fri, 28 Oct 2011)
> New Revision: 64492
> Trac: http://trac.enlightenment.org/e/changeset/64492
> 
> Modified:
>   trunk/ecore/src/lib/ecore_evas/Ecore_Evas.h
> trunk/ecore/src/lib/ecore_evas/ecore_evas.c 
missing changelog and @since

-- 
Mike Blumenkrantz
Zentific: Doctor recommended, mother approved.

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-Devel][Patch] Evas GL Color Format Enum change (and ElmGLview changes accordingly)

[The Rasterman]

On Fri, 28 Oct 2011 14:10:14 +0900 "Sung W. Park"  said:

this one is in svn! approved. good! thanks muchly! :)

> Hi all,
> 
> I'm submitting a patch that changes the color format for Evas GL.
> 
> When I first wrote Evas_GL, I just had EVAS_GL_RGB_8 and EVAS_GL_RGBA_8 and
> etc but it was misleading for some people.  It was more of a filler since
> I couldn't decide on
> a name.  I'm finally changing it to make it more clear.
> 
> typedef enum _Evas_GL_Color_Format
> {
> EVAS_GL_RGB_888 = 0,  // 8 bits per channel
> EVAS_GL_RGBA_ = 1
> } Evas_GL_Color_Format;
> 
> typedef enum _Evas_GL_Depth_Bits
> {
> EVAS_GL_DEPTH_NONE   = 0,
> EVAS_GL_DEPTH_BIT_8  = 1,
> EVAS_GL_DEPTH_BIT_16 = 2,
> EVAS_GL_DEPTH_BIT_24 = 3,
> EVAS_GL_DEPTH_BIT_32 = 4,
> } Evas_GL_Depth_Bits;
> 
> typedef enum _Evas_GL_Stencil_Bits
> {
> EVAS_GL_STENCIL_NONE   = 0,
> EVAS_GL_STENCIL_BIT_1  = 1,
> EVAS_GL_STENCIL_BIT_2  = 2,
> EVAS_GL_STENCIL_BIT_4  = 3,
> EVAS_GL_STENCIL_BIT_8  = 4,
> EVAS_GL_STENCIL_BIT_16 = 5,
> } Evas_GL_Stencil_Bits;
> 
> This will deal with backward compatibility issues as long as we keep the
> ordering and the number same.
> 
> I'm also including an Elmentary patch for elm_glview.c that changes the format
> accordingly.
> 
> Two patches:
>evas_gl_format_change.path// For Evas
>elmglview_evas_gl_format_change.patch   // For Elementary
> 
> 
> Thanks a bunch.
> 
> cheers,
> Sung


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


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Adding array of simple types to an eet.

[The Rasterman]

On Fri, 28 Oct 2011 16:08:52 +1000 David Seikel  said:

> Here's the patch, as promised.

tick! commit it :)

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


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Patch] edje transition from current position

[The Rasterman]

On Thu, 27 Oct 2011 20:49:56 +0900 Jaehwan Kim  said:

much simpler. nicer. commit it (with correct indentation of course). (you have
access to commit - so you do it) :)

> Hi Raster,
> 
> It looks simple and good. So I changed the code as your advice.
> It works well.
> I had a some problem about indentation. If you see the first patch
> "edje_transition_from_current.diff",
> the indentation is not proper. It is why the original code has a tab in
> front of line. I know that
> the tab of the front of line is wrong. So I removed the tabs of the function
> and made the second
> patch file "edje_transition_from_current_with indentation.diff".
> There are many functions have a tabs. I think it must be fixed later.
> Please check two patch files.
> 
> Thanks.
> --
> Jaehwan Kim.
> 
> 
> 
> 2011년 10월 27일 목요일에 Carsten Haitzler님이 작성:
> 
> > On Tue, 25 Oct 2011 05:49:41 + (GMT) Jaehwan Kim <
> > jae.hwan@samsung.com >
> > said:
> >
> > idea -> good. but why double the # of tween modes? why not use a bitmask
> > like
> >
> > typedef enum _Edje_Tween_Mode
> > {
> >   EDJE_TWEEN_MODE_NONE  = 0,
> >   EDJE_TWEEN_MODE_LINEAR= 1,
> >   EDJE_TWEEN_MODE_SINUSOIDAL= 2,
> >   EDJE_TWEEN_MODE_ACCELERATE= 3,
> >   EDJE_TWEEN_MODE_DECELERATE= 4,
> >   EDJE_TWEEN_MODE_ACCELERATE_FACTOR = 5,
> >   EDJE_TWEEN_MODE_DECELERATE_FACTOR = 6,
> >   EDJE_TWEEN_MODE_SINUSOIDAL_FACTOR = 7,
> >   EDJE_TWEEN_MODE_DIVISOR_INTERP= 8,
> >   EDJE_TWEEN_MODE_BOUNCE= 9,
> >   EDJE_TWEEN_MODE_SPRING= 10,
> >   EDJE_TWEEN_MODE_LAST  = 11,
> >   EDJE_TWEEN_MODE_MASK  = 0xff,
> >   EDJE_TWEEN_MODE_OPT_FROM_CURRENT  = (1 << 31)
> > } Edje_Tween_Mode;
> >
> > then do:
> >switch (mode & EDJE_TWEEN_MODE_MASK)
> > ...
> >
> > so u mask out only the lower 8 bits used for mode value. upper 24 can be
> > used
> > for all sorts of bitmask options. then:
> >
> >if ((rp->object) && (pr->tween.mode &
> > EDJE_TWEEN_MODE_OPT_FROM_CURRENT)
> >
> > only - just check for bit being set...
> >
> > in edje_cc_handlers just also set the from current but when param 3 is
> > CURRENT... :)
> >
> > simpler eh? :)
> >
> > >
> > > Dear all
> > >
> > > I made the option which edje transitioEdje_Tween_Moden moves from current
> > > position. Currently, when the part in edc move by transition, it moves
> > from
> > > theone of the states to another of the states even if it is ainimating.
> > > I captured the movie in order to show this operation.
> > > Please show this link.
> > >
> > > http://www.youtube.com/watch?v=p4cqpH5_yyk
> > >
> > > We need it to move from current position, because the animation is not
> > > natural and smooth. So I made the "CURRENT" option.
> > > If I use it, the object move from current and the animation is smooth.
> > > Please show this link. (after patching)
> > >
> > > http://www.youtube.com/watch?v=gC6WT2qTD6g
> > >
> > > It is same in case of color.
> > >
> > > I attached the test.diff too. Just use it for test.
> > >
> > > I think this option is useful for edc transition.
> > > I made "CURRENT" option. But the "movement from current position" is
> > > seem to be more normal than "state1->state2".
> > > So I ask,
> > > How about "movement from current position" is used for default
> > > animation, instead of "CURRENT" option?
> > >
> > > Please check patch file and advise to me.
> > >
> > > Thanks.
> > > --
> > > Jaehwan Kim.
> >
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am" --
> > The Rasterman (Carsten Haitzler)ras...@rasterman.com 
> >
> >
> >
> > --
> > The demand for IT networking professionals continues to grow, and the
> > demand for specialized networking skills is growing even more rapidly.
> > Take a complimentary Learning@Cisco Self-Assessment and learn
> > about Cisco certifications, training, and career opportunities.
> > http://p.sf.net/sfu/cisco-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


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [patch] elm_genlist - add elm_genlist_item_fields_update function

[The Rasterman]

On Fri, 28 Oct 2011 13:25:56 +0900 Daniel Juyung Seo 
said:

for upstream - yes. the new api calls should be in elm_gen.c now :/

> Good patch. Good for all but I think it's better to apply this to
> elm_gen instead of elm_genlist according to the latest upstream
> changes.
> Thanks.
> 
> Daniel Juyung Seo (SeoZ)
> 
> 2011/10/27 Hyoyoung Chang :
> > Hello, it's more revised version of content realize.
> >
> > Thanks
> >
> > -Original Message-
> > From: Hyoyoung Chang [mailto:hyoyoung.ch...@samsung.com]
> > Sent: Thursday, October 27, 2011 2:58 PM
> > To: 'Enlightenment developer list'
> > Subject: RE: [E-devel] [patch] elm_genlist - add
> > elm_genlist_item_fields_update function
> >
> > Hello
> >
> > I revised some naming conventions by seoz's comment.
> > And also attaching new test case for elm_genlist_item_fields_update.
> >
> > Thank you
> >
> > -Original Message-
> > From: Hyoyoung Chang [mailto:hyoyoung.ch...@samsung.com]
> > Sent: Thursday, October 27, 2011 2:06 PM
> > To: 'Enlightenment developer list'
> > Subject: [E-devel] [patch] elm_genlist - add elm_genlist_item_fields_update
> > function
> >
> > Dear developers
> >
> > I made a patch to add elm_genlist_item_fields_update function.
> > It can be used to updating genlist's item part without realize/unrealize
> > itself.
> >
> > Prototype is
> > elm_genlist_item_fields_update
> > (Elm_Genlist_Item *it, const char *part, Elm_Genlist_Item_Field_Flags itf)
> >
> > Part supports globbing. Passing "*" to part means updating all parts.
> > Item field can be one of icon, content and state.
> > I think it's useful to speed up if an app updates frequently.
> >
> > Thanks
> >
> >
> >
> > --
> > The demand for IT networking professionals continues to grow, and the
> > demand for specialized networking skills is growing even more rapidly.
> > Take a complimentary Learning@Cisco Self-Assessment and learn
> > about Cisco certifications, training, and career opportunities.
> > http://p.sf.net/sfu/cisco-dev2dev
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> >
> 
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn 
> about Cisco certifications, training, and career opportunities. 
> http://p.sf.net/sfu/cisco-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


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Commit access request for ecore and elementary

[Mike Blumenkrantz]

On Fri, 28 Oct 2011 18:32:29 +0900
Hyoyoung Chang  wrote:

> To summarize my near future plan, I don't have anything to big commits.
> I'm working frequent on elm. so I think it just speed up applying delay
> time.
> 
> My decision points are that I've been patches to EFL. 
> I feel that I'm enough accustomed with EFL. And I can make contribute.
> So I ask about commit permission to ask for less applying patch times.
> If there's need to big works (maybe a small ones), I'm not qualified.
> 
> Thank you.
> 
> -Original Message-
> From: Mike Blumenkrantz [mailto:m...@zentific.com] 
> Sent: Friday, October 28, 2011 6:09 PM
> To: Enlightenment developer list
> Cc: hyoyo...@gmail.com
> Subject: Re: [E-devel] Commit access request for ecore and elementary
> 
> On Fri, 28 Oct 2011 00:38:25 +0900
> Hyoyoung Chang  wrote:
> 
> > Dear all,
> > Hello. This is Hyoyoung Chang
> > 
> > I write this mail to request the commit permission.
> > Before join EFL, I was working on window manager and copy&paste on X11.
> > 
> > I've contribute ecore and (mostly) elementary.
> > I'd fixed some selection bugs on ecore and modified elementary widgets.
> > My previous works are that adding ellipsis feature to elm_label,
> > enhancing elm_cnp_helper, bugfixing elm_genlist,
> > and adding some functionality to elm widgets.
> > 
> > If I got a commit permission, I'll work on selection(a.k.a. copy&paste)
> and
> > elm widgets.
> > 
> > I got much help of efl community.
> > I really want to say, Thanks for that.
> > And I wish to be a member of EFL community with yours.
> > 
> > Thank you.
> > 
> > PS: I'm on irc as ihyoyoung. but first i is mute letter.
> > 
> >
> 
> --
> > The demand for IT networking professionals continues to grow, and the
> > demand for specialized networking skills is growing even more rapidly.
> > Take a complimentary Learning@Cisco Self-Assessment and learn 
> > about Cisco certifications, training, and career opportunities. 
> > http://p.sf.net/sfu/cisco-dev2dev
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> My question is: what are you actively working on which requires svn access?
> I
> think you've contributed a lot, but I haven't seen many patches out of you
> in
> the past month. Are you working on something big which will require lots of
> commits in the near future?
> 
There's no way to avoid sounding like a dick when I say this, but I feel like
it's going to set precedent otherwise so here goes:

* I personally really appreciate all the work you do, as it has helped me out
* Your work is always of high quality
* You know the areas that you listed very well
* You do not review commits
* You do not review other patches
* You average 1 patch sent to enlightenment-devel every 1-2 weeks

With this said, please check the suggested criteria that I have mentioned in
my longer email. You undoubtedly know elm cnp better than anyone else at this
point, and if you had projects which would require lots of patches being sent
and reviewed I would be all for giving you access. Alternatively, if you were
regularly reviewing patches/commits I would give my +1. It appears that you
aren't doing either right now, however, so I will be -1. Please reply again
right away if either of these things change! :)

-- 
Mike Blumenkrantz
Zentific: Doctor recommended, mother approved.

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Commit Access

[Mike Blumenkrantz]

Hi.

Before I begin, know that I am not thinking of any one person with this email,
nor am I thinking of anyone at all. This is a general email which I am writing
based on my own thoughts after having seen the recent flood of new developers
(which is great!).
Please read it as such and do not read farther into it.

**

SVN commit access for developers in EFL is not a right, it is a privilege. If
you work hard, prove that you are willing to put in the time and effort to make
your code stand out, and own up to your mistakes when you make them (and we
all do), you get commit access. We have no further policy about this, and I
think this laid back atmosphere is one of our greatest strengths.

Because of this, however, we have no precedent for informing new developers of
the "right time" to consider obtaining commit access, nor do we tell them the
basic rules which come with commit access after we give it out. I hope to do
both of those things here.


* WHEN IS THE RIGHT TIME TO ASK FOR COMMIT ACCESS? *
The given answer is "when you feel like you've done enough to deserve it." This
is ambiguous, so I'll try to clear it up. Here are points to consider:

** You are active on enlightenment-devel, staying current with active
   discussions
** You are subscribed to enlightenment-svn
*** You read current commit emails, review the commits, and sometimes point out
bugs or areas which could be fixed
** You submit patches of significant value over a period of months
*** Your patches RARELY require any editing or revision
** You have an area in EFL where you could be called an expert
*** You know the other developers who work in this area or related areas
*** You review patches submitted to enlightenment-devel related to your area of
expertise
** You are regularly in #edevelop * (this really is a requirement nowadays)

If most or all of the above statements apply to you, then you should probably
be getting commit access. If not, consider whether you actually need it;
remember that if you are a committer, YOU ARE RESPONSIBLE FOR ALL CODE WHICH
COMES INTO YOUR INBOX. This means patches, commits, everything. If someone
commits broken code to something that you own or manage, it's YOUR fault if
someone else gets a broken system. If there are patches waiting to be reviewed
for something you work on and you don't review them, THEY WILL NOT GET
COMMITTED.

This brings me to a very relevant point: over the past month(s) I have seen a
lot of complaints that patch reviewing on enlightenment-devel is slow. The
reason why it's slow is because people who have asked for commit access are
either busy or lazy! Usually it's the former, in which case there is nothing to
do but wait. When developers are being lazy, the best thing to do is ask in
#edevelop if someone can review your patch. In fact, this is ALWAYS the first
thing that you should do before submitting a patch. If you get it pre-reviewed,
you have just reduced the time it will sit on enlightenment-devel gathering
dust before raster gets to it.



* WHAT DOES HAVING COMMIT ACCESS MEAN? *
When you are given commit access, this means you are considered responsible
enough to make your own decisions. You should always attempt to observe the
following rules, though at times you will need to break them:

** Do not bug raster about every commit you want to make. Seriously. I realize
   the first few commits can be scary and require hand-holding, but you can
   always come to papa discomfitor who has lots of free time to kill.
** Managing vs Contributing. If you are the SOLE primary committer for a
   component, and people come to you when there are issues with it, then you
   are managing that component. Otherwise, you are contributing. Take this into
   account for your info.txt file to avoid confusion.
** If you are contributing to a component that has a manager, YOU NEED TO TALK
   TO THEM BEFORE MAKING ANY LARGE CHANGES! As an example, everyone knows that
   Tom Hacohen MANAGES textblock, so I would go to him if I wanted to make
   everything someone typed come out backwards. He would tell me that this is
   stupid, veto my patch, and SVN would be saved.
** It is your duty to review ALL code which touches your area(s) of expertise.
   Your area(s) of expertise should be whatever you have listed in
   Managing/Contributing in your info.txt. If you are not comfortable reviewing
   code in an area, you should not be listing it here.
** Commit counts are NOT an indicator of quality, nor an avenue for mature
   individuals to be competing on. If you make 50 commits in a day and do
   nothing but fix formatting and whitespaces, you have effectively worsened
   SVN by creating a large block of useless commits which everyone will then
   have to review to make sure you didn't accidentally break something.

***

Re: [E-devel] Commit access request for ecore and elementary

[Hyoyoung Chang]

To summarize my near future plan, I don't have anything to big commits.
I'm working frequent on elm. so I think it just speed up applying delay
time.

My decision points are that I've been patches to EFL. 
I feel that I'm enough accustomed with EFL. And I can make contribute.
So I ask about commit permission to ask for less applying patch times.
If there's need to big works (maybe a small ones), I'm not qualified.

Thank you.

-Original Message-
From: Mike Blumenkrantz [mailto:m...@zentific.com] 
Sent: Friday, October 28, 2011 6:09 PM
To: Enlightenment developer list
Cc: hyoyo...@gmail.com
Subject: Re: [E-devel] Commit access request for ecore and elementary

On Fri, 28 Oct 2011 00:38:25 +0900
Hyoyoung Chang  wrote:

> Dear all,
> Hello. This is Hyoyoung Chang
> 
> I write this mail to request the commit permission.
> Before join EFL, I was working on window manager and copy&paste on X11.
> 
> I've contribute ecore and (mostly) elementary.
> I'd fixed some selection bugs on ecore and modified elementary widgets.
> My previous works are that adding ellipsis feature to elm_label,
> enhancing elm_cnp_helper, bugfixing elm_genlist,
> and adding some functionality to elm widgets.
> 
> If I got a commit permission, I'll work on selection(a.k.a. copy&paste)
and
> elm widgets.
> 
> I got much help of efl community.
> I really want to say, Thanks for that.
> And I wish to be a member of EFL community with yours.
> 
> Thank you.
> 
> PS: I'm on irc as ihyoyoung. but first i is mute letter.
> 
>

--
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn 
> about Cisco certifications, training, and career opportunities. 
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
My question is: what are you actively working on which requires svn access?
I
think you've contributed a lot, but I haven't seen many patches out of you
in
the past month. Are you working on something big which will require lots of
commits in the near future?

-- 
Mike Blumenkrantz
Zentific: Doctor recommended, mother approved.


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Commit acess request for ecore, edje and elementary

[Mike Blumenkrantz]

On Fri, 28 Oct 2011 09:15:14 +0900
Jihoon Kim  wrote:

> Hello, EFL developers.
> This is Jihoon Kim.
> 
> I'd like to request to get commit permission of EFL svn.
> 
> I am working for Samsung Electronics and in charge of cooperation of EFL and
> input method framework.
> I've mainly contributed patch for typing non-latin languages such as
> Chinese, Japanese, Korean, so on in edje, elementary, e17 using Ecore_IMF.
> 
> In addition, I've also contributed for supporting keyboard input in some
> elementary widget such as calendar, photocam, map, entry, so on.
> 
> I hope I have access permission and a chance to contribute easily in a
> variety of field in EFL.
> 
> Would you please give me commit permission?
> 
> Thanks.
I have the same question for you as I asked Hyoyoung: what are you working on
these days which requires commit access? I know you have submitted some
patches, but I only have a couple patches from you in the past couple months.

I'll go into a bit more detail in another email I'm composing, I don't mean to
single you out here.

-- 
Mike Blumenkrantz
Zentific: Doctor recommended, mother approved.

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Commit access request for ecore and elementary

[Mike Blumenkrantz]

On Fri, 28 Oct 2011 00:38:25 +0900
Hyoyoung Chang  wrote:

> Dear all,
> Hello. This is Hyoyoung Chang
> 
> I write this mail to request the commit permission.
> Before join EFL, I was working on window manager and copy&paste on X11.
> 
> I've contribute ecore and (mostly) elementary.
> I'd fixed some selection bugs on ecore and modified elementary widgets.
> My previous works are that adding ellipsis feature to elm_label,
> enhancing elm_cnp_helper, bugfixing elm_genlist,
> and adding some functionality to elm widgets.
> 
> If I got a commit permission, I'll work on selection(a.k.a. copy&paste) and
> elm widgets.
> 
> I got much help of efl community.
> I really want to say, Thanks for that.
> And I wish to be a member of EFL community with yours.
> 
> Thank you.
> 
> PS: I'm on irc as ihyoyoung. but first i is mute letter.
> 
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn 
> about Cisco certifications, training, and career opportunities. 
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
My question is: what are you actively working on which requires svn access? I
think you've contributed a lot, but I haven't seen many patches out of you in
the past month. Are you working on something big which will require lots of
commits in the near future?

-- 
Mike Blumenkrantz
Zentific: Doctor recommended, mother approved.

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Commit access request for edje and elementry

[The Rasterman]

On Fri, 28 Oct 2011 17:18:46 +0900 Jaehwan Kim  said:

commit it. :) (yes - you. yourself. commit it) :)

> +1 here also, if only so we get edje group inherit docs :P
> >
> 
> I changed some documents about group inheritance.
> Please review. is it enough? or must I do something more?
> 
> Index: src/bin/edje_cc_handlers.c
> ===
> --- src/bin/edje_cc_handlers.c (revision 64481)
> +++ src/bin/edje_cc_handlers.c (work copy)
> @@ -1970,8 +1970,12 @@
>  @parameters
>  [parent group name]
>  @effect
> -Parent group name for inheritance. The parent group have to defined
> -in advance.
> +Parent group name for inheritance.
> +Group "inhreit" is used to inherit any predefined group and change
> +some property which belong to "part", "description", "items" and
> "program".
> +The child group has the same property as parent group. The
> properties
> +can be changed according the name of "part", "description", "items"
> and
> +"program". But the type of the part cannot be changed.
>  @endproperty
>  @since 1.1.0
>  */
> @@ -4562,7 +4566,7 @@
>  [another part's name]
>  @effect
>  Causes a corner to be positioned relatively to another part's
> -container.
> +container. "" means to be positioned relatively to own group.
>  @endproperty
>  */
>  static void
> @@ -4593,6 +4597,7 @@
>  @effect
>  Causes a corner to be positioned relatively to the X axis of
> another
>  part's container. Simply put affects the first parameter of
> "relative".
> +"" means to be positioned relatively to the X axis of own group.
>  @endproperty
>  */
>  static void
> @@ -4622,7 +4627,8 @@
>  @effect
>  Causes a corner to be positioned relatively to the Y axis of
> another
>  part's container. Simply put, affects the second parameter of
> -"relative".
> +"relative". "" means to be positioned relatively to the Y axis
> +own group.
>  @endproperty
>  */
>  static void
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn 
> about Cisco certifications, training, and career opportunities. 
> http://p.sf.net/sfu/cisco-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


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: jypark trunk/devs/jypark

[Mike Blumenkrantz]

On Fri, 28 Oct 2011 17:42:21 +0900
Daniel Juyung Seo  wrote:

> shhh. do not let discomfitor know this TODO.
what what WHAAT
> anyhow, congratulations for your first COMMIT!
> 
> Daniel Juyung Seo (SeoZ)
> 
> On Fri, Oct 28, 2011 at 5:37 PM, Enlightenment SVN
>  wrote:
> > Log:
> > This is my first summit.
> >  TODO list.
> >
> >
> > Author:       jypark
> > Date:         2011-10-28 01:37:58 -0700 (Fri, 28 Oct 2011)
> > New Revision: 64485
> > Trac:         http://trac.enlightenment.org/e/changeset/64485
> >
> > Added:
> >  trunk/devs/jypark/TODO
> >
> >
> > --
> > The demand for IT networking professionals continues to grow, and the
> > demand for specialized networking skills is growing even more rapidly.
> > Take a complimentary Learning@Cisco Self-Assessment and learn
> > about Cisco certifications, training, and career opportunities.
> > http://p.sf.net/sfu/cisco-dev2dev
> > ___
> > enlightenment-svn mailing list
> > enlightenment-...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
> >
> 
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn 
> about Cisco certifications, training, and career opportunities. 
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
Mike Blumenkrantz
Zentific: Doctor recommended, mother approved.

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: jypark trunk/devs/jypark

[Daniel Juyung Seo]

shhh. do not let discomfitor know this TODO.
anyhow, congratulations for your first COMMIT!

Daniel Juyung Seo (SeoZ)

On Fri, Oct 28, 2011 at 5:37 PM, Enlightenment SVN
 wrote:
> Log:
> This is my first summit.
>  TODO list.
>
>
> Author:       jypark
> Date:         2011-10-28 01:37:58 -0700 (Fri, 28 Oct 2011)
> New Revision: 64485
> Trac:         http://trac.enlightenment.org/e/changeset/64485
>
> Added:
>  trunk/devs/jypark/TODO
>
>
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: antognolli IN trunk/ecore/src/lib: ecore_evas ecore_fb

[vtorri]

Changelog

Vincent

Quoting Enlightenment SVN :

> Log:
> ecore/fb: Change fb engine input to use ecore_input_evas.
>  Nothing changes, only making the ecore fb engine to send keyboard and
>  mouse events using ecore_input_evas, instead of its own ecore events.
>
>  Patch for SiT.
>
>
>
> Author:   antognolli
> Date: 2011-10-27 12:29:08 -0700 (Thu, 27 Oct 2011)
> New Revision: 64447
> Trac: http://trac.enlightenment.org/e/changeset/64447
>
> Modified:
>  trunk/ecore/src/lib/ecore_evas/Ecore_Evas.h 
> trunk/ecore/src/lib/ecore_evas/ecore_evas.c 
> trunk/ecore/src/lib/ecore_evas/ecore_evas_fb.c 
> trunk/ecore/src/lib/ecore_fb/Ecore_Fb.h 
> trunk/ecore/src/lib/ecore_fb/Makefile.am 
> trunk/ecore/src/lib/ecore_fb/ecore_fb.c 
> trunk/ecore/src/lib/ecore_fb/ecore_fb_li.c 
> trunk/ecore/src/lib/ecore_fb/ecore_fb_private.h 
> trunk/ecore/src/lib/ecore_fb/ecore_fb_ts.c 
> trunk/ecore/src/lib/ecore_fb/ecore_fb_vt.c
>
> Modified: trunk/ecore/src/lib/ecore_evas/Ecore_Evas.h
> ===
> --- trunk/ecore/src/lib/ecore_evas/Ecore_Evas.h   2011-10-27 19:12:53 
> UTC (rev 64446)
> +++ trunk/ecore/src/lib/ecore_evas/Ecore_Evas.h   2011-10-27 19:29:08 
> UTC (rev 64447)
> @@ -1366,6 +1366,28 @@
> EAPI voidecore_evas_manual_render_set(Ecore_Evas *ee, 
> Eina_Bool manual_render);
> EAPI Eina_Bool   ecore_evas_manual_render_get(const Ecore_Evas *ee);
>
> +/**
> + * @brief Registers an @c Ecore_Evas to receive events through 
> ecore_input_evas.
> + *
> + * @param ee The @c Ecore_Evas handle.
> + *
> + * This function calls ecore_event_window_register() with the @p ee 
> as its @c
> + * id argument, @c window argument, and uses its @c Evas too. It is 
> useful when
> + * no @c window information is available on a given @c Ecore_Evas backend.
> + *
> + * @see ecore_evas_input_event_unregister()
> + * @since 1.1
> + */
> +EAPI voidecore_evas_input_event_register(Ecore_Evas *ee);
> +/**
> + * @brief Unregisters an @c Ecore_Evas receiving events through 
> ecore_input_evas.
> + *
> + * @param ee The @c Ecore_Evas handle.
> + *
> + * @see ecore_evas_input_event_register()
> + * @since 1.1
> + */
> +EAPI voidecore_evas_input_event_unregister(Ecore_Evas *ee);
>
> /**
>  * @brief Force immediate rendering on a given @c Ecore_Evas window
>
> Modified: trunk/ecore/src/lib/ecore_evas/ecore_evas.c
> ===
> --- trunk/ecore/src/lib/ecore_evas/ecore_evas.c   2011-10-27 19:12:53 
> UTC (rev 64446)
> +++ trunk/ecore/src/lib/ecore_evas/ecore_evas.c   2011-10-27 19:29:08 
> UTC (rev 64447)
> @@ -2519,3 +2519,19 @@
>
>return l;
> }
> +
> +EAPI void
> +ecore_evas_input_event_register(Ecore_Evas *ee)
> +{
> +   ecore_event_window_register((Ecore_Window)ee, ee, ee->evas,
> +   
> (Ecore_Event_Mouse_Move_Cb)_ecore_evas_mouse_move_process,
> +   
> (Ecore_Event_Multi_Move_Cb)_ecore_evas_mouse_multi_move_process,
> +   
> (Ecore_Event_Multi_Down_Cb)_ecore_evas_mouse_multi_down_process,
> +   
> (Ecore_Event_Multi_Up_Cb)_ecore_evas_mouse_multi_up_process);
> +}
> +
> +EAPI void
> +ecore_evas_input_event_unregister(Ecore_Evas *ee)
> +{
> +   ecore_event_window_unregister((Ecore_Window)ee);
> +}
>
> Modified: trunk/ecore/src/lib/ecore_evas/ecore_evas_fb.c
> ===
> --- trunk/ecore/src/lib/ecore_evas/ecore_evas_fb.c2011-10-27 
> 19:12:53 UTC (rev 64446)
> +++ trunk/ecore/src/lib/ecore_evas/ecore_evas_fb.c2011-10-27 
> 19:29:08 UTC (rev 64447)
> @@ -20,10 +20,10 @@
>
> static char *ecore_evas_default_display = "0";
> static Eina_List *ecore_evas_input_devices = NULL;
> -static Ecore_Event_Handler *ecore_evas_event_handlers[6] = {NULL, 
> NULL, NULL, NULL, NULL, NULL};
> +static Ecore_Event_Handler *ecore_evas_event_handlers[4] = {NULL, 
> NULL, NULL, NULL};
>
> static void
> -_ecore_evas_mouse_move_process_fb(Ecore_Evas *ee, int x, int y, 
> unsigned int timestamp)
> +_ecore_evas_mouse_move_process_fb(Ecore_Evas *ee, int x, int y)
> {
>int fbw, fbh;
>
> @@ -50,14 +50,6 @@
>y - ee->prop.cursor.hot.x,
>(fbw - ee->w) + ee->w - x - 1 - 
> ee->prop.cursor.hot.y);
>  }
> -   if (ee->rotation == 0)
> - evas_event_feed_mouse_move(ee->evas, x, y, timestamp, NULL);
> -   else if (ee->rotation == 90)
> - evas_event_feed_mouse_move(ee->evas, (fbh - ee->h) + ee->h - y 
> - 1, x, timestamp, NULL);
> -   else if (ee->rotation == 180)
> - evas_event_feed_mouse_move(ee->evas, (fbw - ee->w) + ee->w - x 
> - 1, (fbh - ee->h) + ee->h - y - 1, timestamp, NULL);
> -   else if (ee->rotation == 270)
> - evas_event_feed_mouse_move(ee->evas, y, (fbw - ee->w) + ee->w - 
> x - 1, timestamp, NULL);
> }
>
> static Ecore_Evas *fb_ee = NULL;
> @@ -10

Re: [E-devel] E SVN: devilhorns trunk/emprint/src/bin

[Mike Blumenkrantz]

On Fri, 28 Oct 2011 10:37:03 +0200
vto...@univ-evry.fr wrote:

> Quoting Enlightenment SVN :
> 
> > Log:
> > Emprint: Better check against double extension in filename.
> 
> eina should have some functions abou filename extensions
> 
> Vincent
> 
> >
> >
> >
> > Author:   devilhorns
> > Date: 2011-10-27 11:54:18 -0700 (Thu, 27 Oct 2011)
> > New Revision: 64443
> > Trac: http://trac.enlightenment.org/e/changeset/64443
> >
> > Modified:
> >  trunk/emprint/src/bin/main.c
> >
> > Modified: trunk/emprint/src/bin/main.c
> > ===
> > --- trunk/emprint/src/bin/main.c2011-10-27 18:50:33 UTC (rev 64442)
> > +++ trunk/emprint/src/bin/main.c2011-10-27 18:54:18 UTC (rev 64443)
> > @@ -323,8 +323,13 @@
> >   else
> > snprintf(buf, sizeof(buf), "%s/%s%s", dir, file, ext);
> >}
> > - else
> > -   snprintf(buf, sizeof(buf), "%s/%s", dir, file);
> > + else
> > +   {
> > +  if (!strrchr(file, '.'))
> > +snprintf(buf, sizeof(buf), "%s/%s.png", dir, file);
> > +  else
> > +snprintf(buf, sizeof(buf), "%s/%s", dir, file);
> > +   }
> >   }
> >  }
> >
> >
> >
> > --
> > The demand for IT networking professionals continues to grow, and the
> > demand for specialized networking skills is growing even more rapidly.
> > Take a complimentary Learning@Cisco Self-Assessment and learn
> > about Cisco certifications, training, and career opportunities.
> > http://p.sf.net/sfu/cisco-dev2dev
> > ___
> > enlightenment-svn mailing list
> > enlightenment-...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
> >
> >
> 
> 
> 
> 
> This message was sent using IMP, the Internet Messaging Program.
> 
> 
> 
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn 
> about Cisco certifications, training, and career opportunities. 
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
it has eina_str_has_extension, but then he wouldn't get to implement it himself

-- 
Mike Blumenkrantz
Zentific: Doctor recommended, mother approved.

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-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/emprint/src/bin

[vtorri]

Quoting Enlightenment SVN :

> Log:
> Emprint: Better check against double extension in filename.

eina should have some functions abou filename extensions

Vincent

>
>
>
> Author:   devilhorns
> Date: 2011-10-27 11:54:18 -0700 (Thu, 27 Oct 2011)
> New Revision: 64443
> Trac: http://trac.enlightenment.org/e/changeset/64443
>
> Modified:
>  trunk/emprint/src/bin/main.c
>
> Modified: trunk/emprint/src/bin/main.c
> ===
> --- trunk/emprint/src/bin/main.c  2011-10-27 18:50:33 UTC (rev 64442)
> +++ trunk/emprint/src/bin/main.c  2011-10-27 18:54:18 UTC (rev 64443)
> @@ -323,8 +323,13 @@
>   else
> snprintf(buf, sizeof(buf), "%s/%s%s", dir, file, ext);
>}
> - else
> -   snprintf(buf, sizeof(buf), "%s/%s", dir, file);
> + else
> +   {
> +  if (!strrchr(file, '.'))
> +snprintf(buf, sizeof(buf), "%s/%s.png", dir, file);
> +  else
> +snprintf(buf, sizeof(buf), "%s/%s", dir, file);
> +   }
> }
>  }
>
>
>
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
>




This message was sent using IMP, the Internet Messaging Program.



--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Elementary Map Issues

[Kim Yunhan]

On Fri, Oct 28, 2011 at 1:27 PM, Carsten Haitzler wrote:

> On Fri, 28 Oct 2011 13:19:58 +0900 Bluezery  said:
>
> > Dear all,
> >
> > I am interested in elm_map widget.
> > As far as I know, elm_map is a only widget use network resource in
> > elementary.
> > So, when the network condition is poor, some map images can not be
> visible
> > while progress bar is still running.
> >
> > Due to above issues, I have checked the elm_map code roughly.
> > And I have found that there are two issues.
> >
> > First one is related to progress bar.
> > Only if ecore_file_download_full() returns success, progress bar
> disappears.
> > If it returns error, progress bar runs continuously. It can be fixed
> easily
> > I think.
>
> that's a bug. person doing the coding and testing wasnt getting download
> errors
> i guess :)
>
> > Second one is about invisible images and controversial problem.
> > If image downloading fails, the only way to download again is user input.
> > The application do not know download failure.
> > If application know it, application itself will be able to reload elm_map
> or
> > show error pop-up, etc. (without user input)
> > So, I suggest that "download,fail" signal  should be added to inform
> > applications of download failure.
>

I think "download,failed" is more proper in this situation. :-)
And this signal helps the application can decide to check poor internet
connection.
So I think it is needed.


> > Also, re-load functionality may be needed to retry downloading. There may
> be
> > two different ways about re-load functionality.
> > (1) Add elm_map_reload() function (The name must fit in the EFL
> convention.)
> > (2) Add elm_map_smart_object_get()/elm_map_smart_object_set() functions
> so
> > application can request elm_object_smart_changed() for one self.
>
> i would honestly expect elm_map itself tried reloads after failures - it
> should
> try again immediately on failure the first time for a tile, then next
> failure
> back off for 1 sec, try again, then back off for 2 seconds next failure,
> then
> 4, then 8, then 16, and maybe give up after that - either way it would:
>
> 1. retry a few times with back-off timeouts in case connection or server is
> overloaded
> 2. after enough retries, give up.
>
> i'd expect this to be its default behavior. yes a reload function could be
> useful in addition as well as some callback to inform the app that there
> has
> been an error and let the app decide. i'd say you need 2 callbacks. 1 for
> each
> error when elm_map does its own retry, and a different callback for when
> the
> last error comes in before elm_map then gives up doing retries for that
> tile.
> let the app decide in both cases what it wants to do then (inform the user
> that
> connection is bad if it gets too many of the first kind of error, inform
> the
> user on give-up errors, issue re-loads etc. etc.)
>
>
Yes, elm_map tried to reload itself is best solution, I think.
But elementary can't detect internet connection.
So if the retry logic is given, it should controlled by the application.


> > Above two suggestions can be debated.
> > I would like to hear EFL developers' opinions.
> >
> > Thanks.
> > Kim.
> >
> --
> > The demand for IT networking professionals continues to grow, and the
> > demand for specialized networking skills is growing even more rapidly.
> > Take a complimentary Learning@Cisco Self-Assessment and learn
> > about Cisco certifications, training, and career opportunities.
> > http://p.sf.net/sfu/cisco-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
>
>
>
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mail

Re: [E-devel] E SVN: discomfitor trunk/devs/discomfitor

[Mike Blumenkrantz]

On Fri, 28 Oct 2011 17:25:59 +0900
Daniel Juyung Seo  wrote:

> this is awesome!
> this reminded you on cebit.
> any plans to come to Korea?
> 
> Daniel Juyung Seo (SeoZ)
> 
> On Fri, Oct 28, 2011 at 2:49 PM, Enlightenment SVN
>  wrote:
> > Log:
> > not enough beards on svn so I'm gonna beard it up with some pre-shave pics
> > from after cebit
> >
> >
> > Author:       discomfitor
> > Date:         2011-10-27 22:49:05 -0700 (Thu, 27 Oct 2011)
> > New Revision: 64481
> > Trac:         http://trac.enlightenment.org/e/changeset/64481
> >
> > Added:
> >  trunk/devs/discomfitor/icon-big.png trunk/devs/discomfitor/icon-med.png
> > trunk/devs/discomfitor/icon-sml.png
> >
> >
> > Property changes on: trunk/devs/discomfitor/icon-big.png
> > ___
> > Added: svn:mime-type
> >   + application/octet-stream
> >
> >
> > Property changes on: trunk/devs/discomfitor/icon-med.png
> > ___
> > Added: svn:mime-type
> >   + application/octet-stream
> >
> >
> > Property changes on: trunk/devs/discomfitor/icon-sml.png
> > ___
> > Added: svn:mime-type
> >   + application/octet-stream
> >
> >
> > --
> > The demand for IT networking professionals continues to grow, and the
> > demand for specialized networking skills is growing even more rapidly.
> > Take a complimentary Learning@Cisco Self-Assessment and learn
> > about Cisco certifications, training, and career opportunities.
> > http://p.sf.net/sfu/cisco-dev2dev
> > ___
> > enlightenment-svn mailing list
> > enlightenment-...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
> >
> 
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn 
> about Cisco certifications, training, and career opportunities. 
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
working on it. too busy eating bacon to go any time soon. plus, if I went now
then I would have to come up with a good excuse for missing your wedding!

-- 
Mike Blumenkrantz
Zentific: Doctor recommended, mother approved.

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: discomfitor trunk/devs/discomfitor

[David Seikel]

On Fri, 28 Oct 2011 17:25:59 +0900 Daniel Juyung Seo
 wrote:

> this is awesome!
> this reminded you on cebit.
> any plans to come to Korea?
> 
> Daniel Juyung Seo (SeoZ)
> 
> On Fri, Oct 28, 2011 at 2:49 PM, Enlightenment SVN
>  wrote:
> > Log:
> > not enough beards on svn so I'm gonna beard it up with some
> > pre-shave pics from after cebit

Um, wait, what?  Koreans like beards?  Maybe I should move?

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


signature.asc
Description: PGP signature
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Commit access request for edje and elementry

[Mike Blumenkrantz]

On Fri, 28 Oct 2011 17:18:46 +0900
Jaehwan Kim  wrote:

> +1 here also, if only so we get edje group inherit docs :P
> >
> 
> I changed some documents about group inheritance.
> Please review. is it enough? or must I do something more?
> 
> Index: src/bin/edje_cc_handlers.c
> ===
> --- src/bin/edje_cc_handlers.c (revision 64481)
> +++ src/bin/edje_cc_handlers.c (work copy)
> @@ -1970,8 +1970,12 @@
>  @parameters
>  [parent group name]
>  @effect
> -Parent group name for inheritance. The parent group have to defined
> -in advance.
> +Parent group name for inheritance.
> +Group "inhreit" is used to inherit any predefined group and change
  inherit
> +some property which belong to "part", "description", "items" and
   belongs  or
> "program".
> +The child group has the same property as parent group. The
> properties
> +can be changed according the name of "part", "description", "items"
> and
this line is confusing, saying less would actually be more helpful
> +"program". But the type of the part cannot be changed.
also worth stating is that if you specify the type again in an inherited part,
it will cause an error (unless you plan to fix that)
>  @endproperty
>  @since 1.1.0
>  */
> @@ -4562,7 +4566,7 @@
>  [another part's name]
>  @effect
>  Causes a corner to be positioned relatively to another part's
> -container.
> +container. "" means to be positioned relatively to own group.
mm this is wrong and confusing. something more like
[[
Setting to "" will un-set this value for inherited parts.
]]
since you would only ever use it with group inheritance
>  @endproperty
>  */
>  static void
> @@ -4593,6 +4597,7 @@
>  @effect
>  Causes a corner to be positioned relatively to the X axis of
> another
>  part's container. Simply put affects the first parameter of
> "relative".
> +"" means to be positioned relatively to the X axis of own group.
same as above
>  @endproperty
>  */
>  static void
> @@ -4622,7 +4627,8 @@
>  @effect
>  Causes a corner to be positioned relatively to the Y axis of
> another
>  part's container. Simply put, affects the second parameter of
> -"relative".
> +"relative". "" means to be positioned relatively to the Y axis
> +own group.
same as above
>  @endproperty
>  */
>  static void
definitely an improvement. A for effort.

-- 
Mike Blumenkrantz
Zentific: Doctor recommended, mother approved.

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: discomfitor trunk/devs/discomfitor

[Daniel Juyung Seo]

this is awesome!
this reminded you on cebit.
any plans to come to Korea?

Daniel Juyung Seo (SeoZ)

On Fri, Oct 28, 2011 at 2:49 PM, Enlightenment SVN
 wrote:
> Log:
> not enough beards on svn so I'm gonna beard it up with some pre-shave pics 
> from after cebit
>
>
> Author:       discomfitor
> Date:         2011-10-27 22:49:05 -0700 (Thu, 27 Oct 2011)
> New Revision: 64481
> Trac:         http://trac.enlightenment.org/e/changeset/64481
>
> Added:
>  trunk/devs/discomfitor/icon-big.png trunk/devs/discomfitor/icon-med.png 
> trunk/devs/discomfitor/icon-sml.png
>
>
> Property changes on: trunk/devs/discomfitor/icon-big.png
> ___
> Added: svn:mime-type
>   + application/octet-stream
>
>
> Property changes on: trunk/devs/discomfitor/icon-med.png
> ___
> Added: svn:mime-type
>   + application/octet-stream
>
>
> Property changes on: trunk/devs/discomfitor/icon-sml.png
> ___
> Added: svn:mime-type
>   + application/octet-stream
>
>
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] svn account access kill list

[David Seikel]

On Fri, 28 Oct 2011 03:24:43 -0400 Mike Blumenkrantz
 wrote:

> On Fri, 28 Oct 2011 17:13:57 +1000
> David Seikel  wrote:
> 
> > On Fri, 28 Oct 2011 15:43:00 +0900 Carsten Haitzler (The Rasterman)
> >  wrote:
> > 
> > > i've built a list of people with accounts that have not done
> > > anything pretty much all of this year (since rev 56000). if
> > > you're on this list and think that you want to keep access, then
> > > make your case as to why you should.
> > 
> > Yay! I dodge the bullet yet again.  B-)
> > 
> how does an email bot have commit access???

Coz I run on the svn server as root?  Blame raster, he wrote 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
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Commit access request for edje and elementry

[Jaehwan Kim]

+1 here also, if only so we get edje group inherit docs :P
>

I changed some documents about group inheritance.
Please review. is it enough? or must I do something more?

Index: src/bin/edje_cc_handlers.c
===
--- src/bin/edje_cc_handlers.c (revision 64481)
+++ src/bin/edje_cc_handlers.c (work copy)
@@ -1970,8 +1970,12 @@
 @parameters
 [parent group name]
 @effect
-Parent group name for inheritance. The parent group have to defined
-in advance.
+Parent group name for inheritance.
+Group "inhreit" is used to inherit any predefined group and change
+some property which belong to "part", "description", "items" and
"program".
+The child group has the same property as parent group. The
properties
+can be changed according the name of "part", "description", "items"
and
+"program". But the type of the part cannot be changed.
 @endproperty
 @since 1.1.0
 */
@@ -4562,7 +4566,7 @@
 [another part's name]
 @effect
 Causes a corner to be positioned relatively to another part's
-container.
+container. "" means to be positioned relatively to own group.
 @endproperty
 */
 static void
@@ -4593,6 +4597,7 @@
 @effect
 Causes a corner to be positioned relatively to the X axis of
another
 part's container. Simply put affects the first parameter of
"relative".
+"" means to be positioned relatively to the X axis of own group.
 @endproperty
 */
 static void
@@ -4622,7 +4627,8 @@
 @effect
 Causes a corner to be positioned relatively to the Y axis of
another
 part's container. Simply put, affects the second parameter of
-"relative".
+"relative". "" means to be positioned relatively to the Y axis
+own group.
 @endproperty
 */
 static void
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] svn account access kill list

[Mike Blumenkrantz]

On Fri, 28 Oct 2011 17:13:57 +1000
David Seikel  wrote:

> On Fri, 28 Oct 2011 15:43:00 +0900 Carsten Haitzler (The Rasterman)
>  wrote:
> 
> > i've built a list of people with accounts that have not done anything
> > pretty much all of this year (since rev 56000). if you're on this
> > list and think that you want to keep access, then make your case as
> > to why you should.
> 
> Yay! I dodge the bullet yet again.  B-)
> 
how does an email bot have commit access???

-- 
Mike Blumenkrantz
Zentific: Doctor recommended, mother approved.

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] svn account access kill list

[David Seikel]

On Fri, 28 Oct 2011 15:43:00 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> i've built a list of people with accounts that have not done anything
> pretty much all of this year (since rev 56000). if you're on this
> list and think that you want to keep access, then make your case as
> to why you should.

Yay! I dodge the bullet yet again.  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
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel