Re: [E-devel] [Patch][elm_map] Remove unnecessary flags

[Bluezery]

Previous patch has a bug.

Fixed patch is attached.
I have changed as below.
//  _process_download_list(gi->wd->obj);  -->
_process_download_list(gi->wd->obj);

On Sat, Nov 12, 2011 at 3:51 PM, Bluezery  wrote:
> Hi,
>
> There are too may flags in elm_map. Most of them are duplicated and 
> unnecessary.
> I have removed "want", "download", "have" variables.
>
> I use gi->job instead of "want" & "download".
> I use ecore_file_exists() instead of "have" flags.
>
> Please review attached patch file.
>
Index: src/lib/elm_map.c
===
--- src/lib/elm_map.c	(리비전 65087)
+++ src/lib/elm_map.c	(작업 사본)
@@ -250,9 +250,7 @@ struct _Grid_Item
struct {
 int x, y, w, h;
} src, out;
-   Eina_Bool want : 1;
-   Eina_Bool download : 1;
-   Eina_Bool have : 1;
+
Ecore_File_Download_Job *job;
int try_num;
 };
@@ -1154,14 +1152,12 @@ grid_clear(Evas_Object *obj, Grid *g)
 //evas_object_del(gi->txt);
 
 wd->download_list = eina_list_remove(wd->download_list, gi);
-gi->want = EINA_FALSE;
 
 if (gi->job)
   {
  DBG("DOWNLOAD abort %s", gi->file);
  ecore_file_download_abort(gi->job);
  ecore_file_remove(gi->file);
- gi->have = EINA_FALSE;
  gi->job = NULL;
  wd->try_num--;
   }
@@ -1182,24 +1178,19 @@ grid_clear(Evas_Object *obj, Grid *g)
 static void
 _tile_update(Grid_Item *gi)
 {
-   gi->want = EINA_FALSE;
-   gi->download = EINA_FALSE;
evas_object_image_file_set(gi->img, gi->file, NULL);
if (evas_object_image_load_error_get(gi->img) != EVAS_LOAD_ERROR_NONE)
  {
 ERR("Image loading error (%s)", gi->file);
 ecore_file_remove(gi->file);
-gi->have = EINA_FALSE;
-return;
  }
-
-   obj_rotate_zoom(gi->wd->obj, gi->img);
-   evas_object_show(gi->img);
-
-   //evas_object_text_text_set(gi->txt, gi->file);
-   //evas_object_show(gi->txt);
-
-   gi->have = EINA_TRUE;
+   else
+ {
+   obj_rotate_zoom(gi->wd->obj, gi->img);
+   evas_object_show(gi->img);
+   //evas_object_text_text_set(gi->txt, gi->file);
+   //evas_object_show(gi->txt);
+ }
 }
 
 static void
@@ -1207,25 +1198,21 @@ _tile_downloaded(void *data, const char
 {
Grid_Item *gi = data;
 
-   gi->wd->download_num--;
-   gi->download = EINA_FALSE;
gi->job = NULL;
 
-   if ((gi->want) && (status == 200))
+   if (status == 200)
  {
+DBG("Download success from %s to %s", gi->source, gi->file);
 _tile_update(gi);
-DBG("DOWNLOAD done %s", gi->file);
  }
-
-   if (status != 200)
+   else
  {
-DBG("Download failed %s (%d) ", gi->file, status);
+DBG("Download failed from %s to %s (%d) ", gi->source, gi->file, status);
 ecore_file_remove(gi->file);
-gi->have = EINA_FALSE;
  }
-   else
- gi->wd->finish_num++;
 
+   gi->wd->finish_num++;
+   gi->wd->download_num--;
evas_object_smart_callback_call(gi->wd->obj, SIG_DOWNLOADED, NULL);
if (!gi->wd->download_num)
  {
@@ -1274,19 +1261,16 @@ _process_download_list(Evas_Object *obj)
  ww, hh,
  cvx, cvy, cvw, cvh))
   {
- gi->download = EINA_FALSE;
  wd->download_list = eina_list_remove(wd->download_list, gi);
   }
  }
 
EINA_LIST_REVERSE_FOREACH_SAFE(wd->download_list, l, ll, gi)
  {
-if (gi->wd->download_num >= MAX_CONCURRENT_DOWNLOAD)
-  break;
+if (gi->wd->download_num >= MAX_CONCURRENT_DOWNLOAD) break;
 
 Eina_Bool ret = ecore_file_download_full(gi->source, gi->file, _tile_downloaded, NULL, gi, &(gi->job), wd->ua);
-if (!ret || !gi->job)
-  WRN("Can't start to download %s to %s", gi->source, gi->file);
+if (!ret || !gi->job) ERR("Can't start to download from %s to %s", gi->source, gi->file);
 else
   {
  gi->wd->download_num++;
@@ -1304,8 +1288,7 @@ _add_download_list(Evas_Object *obj, Gri
ELM_CHECK_WIDTYPE(obj, widtype);
Widget_Data *wd = elm_widget_data_get(obj);
 
-   wd->download_list = eina_list_remove(wd->download_list, gi);
-   wd->download_list = eina_list_append(wd->download_list, gi);
+   if (!eina_list_data_find(wd->download_list, gi)) wd->download_list = eina_list_append(wd->download_list, gi);
_process_download_list(obj);
 }
 
@@ -1393,33 +1376,20 @@ grid_load(Evas_Object *obj, Grid *g)
  ww, hh,
  cvx, cvy, cvw, cvh))
   {
- if (gi->want)
+ if (ecore_file_exists(gi->file))
{
   evas_object_hide(gi->img);
-  //evas_object_hide(gi->txt);
   evas_object_image_file_set(gi->img, NULL, NULL);
-  gi->want = EINA_FALSE;
-  gi->have = EINA_FALSE;
-
-  if (gi-

Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib

[The Rasterman]

On Sat, 12 Nov 2011 07:53:02 +0100 (CET) Vincent Torri 
said:

> 
> 
> On Sat, 12 Nov 2011, Carsten Haitzler (The Rasterman) wrote:
> 
> > On Fri, 11 Nov 2011 20:08:09 -0500 Christopher Michael
> >  said:
> >
> >> On 11/11/11 19:54, Enlightenment SVN wrote:
> >>> Log:
> >>> back to unsigned long. code was actually correct as-is.
> >>>
> >> If that's actually correct, then the 'fix' for the xcb version should be
> >> reverted also ;)
> >
> > yeah  found it. fixed. :) thanks for reminding
> >
> > fyi - notice that even with those changes.. a whole bunch of other funcs in
> > the same file were still using unsigned long * so the code was
> > inconsistently changed too... which is bad :)
> 
> forget my previous mail
> 
> I do not agree. I don't see anywhere in the protocol specification where a 
> long is used:
> 
> http://cgit.freedesktop.org/xorg/proto/xproto/tree/specs/encoding.xml
> http://cgit.freedesktop.org/xorg/proto/xproto/tree/specs/sect1-9.xml

protocol can never specify a long because longs are a variables size. protocol
specifies 32bit integers (CARD32). the Xlib API packs 1 card32 into each long
in the array. trust me on this... if you don't - get a 64bit machine and find
out :)

> Vincent
> 
> >
> >> dh
> >>
> >>>
> >>>
> >>> Author:   raster
> >>> Date: 2011-11-11 16:54:22 -0800 (Fri, 11 Nov 2011)
> >>> New Revision: 65082
> >>> Trac: http://trac.enlightenment.org/e/changeset/65082
> >>>
> >>> Modified:
> >>>trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c
> >>>
> >>> Modified: trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c
> >>> ===
> >>> --- trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c
> >>> 2011-11-11 21:59:02 UTC (rev 65081) +++
> >>> trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c2011-11-12
> >>> 00:54:22 UTC (rev 65082) @@ -131,7 +131,7 @@ return -1;
> >>> }
> >>>   for (i = 0; i<  num_ret; i++)
> >>> -  val[i] = ((unsigned int *)prop_ret)[i];
> >>> +  val[i] = ((unsigned long *)prop_ret)[i];
> >>>   num = num_ret;
> >>>   *plst = val;
> >>>}
> >>>
> >>
> >>
> >> --
> >> RSA(R) Conference 2012
> >> Save $700 by Nov 18
> >> Register now
> >> http://p.sf.net/sfu/rsa-sfdev2dev1
> >> ___
> >> 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
> >
> >
> > --
> > RSA(R) Conference 2012
> > Save $700 by Nov 18
> > Register now
> > http://p.sf.net/sfu/rsa-sfdev2dev1
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> >
> 
> --
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> ___
> 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


--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] e_fm build and mount problems

[Vincent Torri]

Hey,

On Sat, 12 Nov 2011, Vincent Torri wrote:

> Hi all,
>
> I was trying to dig deeper into a problem where I get a corruption in
> e_fm when mounting and removing a usb disk (see
> here:http://marc.info/?l=enlightenment-devel&m=132014458110340&w=2 for
> details). I found a couple of problems when trying to build e with
> different e_fm options.
>
> 1. when efl is installed in /opt/ for example eeze_mount is always
> disabled because the configure test fails because of a missing
> -L/opt/e17 in the compile.

i don't have libmount, so I can't test it. Can you paste config.log of 
eeze, please ?

>
> 2. configure help says enable hal device backend is disabled by default,
> however I always have it enabled after configure

there is indeed a problem with hal device *backend* (which is actually not 
disabled by default), but the variable e_cv_want_device_hal is anyway not 
used at all. So I'm wondering why that part of code is still in 
configure.ac

hal *mount* is enabled by default, and that's what is displayed in the 
configure output:

Preferred Backends:
  * device..: eeze
  * hal_mount...: enabled
  * udisks_mount: enabled
  * eeze_mount..:

I think i've fixed that in svn. Tell me if there's something wrong.

> 3. when I pass --disable-mount-hal to configure the build of
> e_fm_main_udisks fails with the following error:
>
> /usr/bin/ld: e_fm_main_udisks.o: undefined reference to symbol
> 'e_dbus_method_call_send'
> /usr/bin/ld: note: 'e_dbus_method_call_send' is defined in DSO
> /opt/e17/lib/libedbus.so.1 so try adding it to the linker command line
> /opt/e17/lib/libedbus.so.1: could not read symbols: Invalid operation

no problem here. The symbol e_dbus_method_call_send is in my libedbus. I 
don't know what the problem could be. That symbol exists since e_dbus 1.0.

Note that the EFL are not in /opt/ in my case.

> collect2: ld returned 1 exit status
> make[4]: *** [enlightenment_fm] Error 1
> make[4]: Leaving directory
> `/home/jschrod/Downloads/Enlightenment/e17_src/e/src/bin/e_fm'
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory
> `/home/jschrod/Downloads/Enlightenment/e17_src/e/src/bin'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory
> `/home/jschrod/Downloads/Enlightenment/e17_src/e/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/jschrod/Downloads/Enlightenment/e17_src/e'
> make: *** [all] Error 2
> /usr/bin/ld: e_fm_main_udisks.o: undefined reference to symbol
> 'e_dbus_method_call_send'
> /usr/bin/ld: note: 'e_dbus_method_call_send' is defined in DSO
> /opt/e17/lib/libedbus.so.1 so try adding it to the linker command line
> /opt/e17/lib/libedbus.so.1: could not read symbols: Invalid operation
> collect2: ld returned 1 exit status
> make[4]: *** [enlightenment_fm] Error 1
> make[4]: Leaving directory
> `/home/jschrod/Downloads/Enlightenment/e17_src/e/src/bin/e_fm'
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory
> `/home/jschrod/Downloads/Enlightenment/e17_src/e/src/bin'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory
> `/home/jschrod/Downloads/Enlightenment/e17_src/e/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/jschrod/Downloads/Enlightenment/e17_src/e'
> make: *** [all] Error 2
>
> 4. building after configure with --disable-mount-hal and
> --disable-mount-udisks works (after fixing 1 by exporting LIBRARY_PATH).
> However the icons for usb-disks never show up on the screen although
> they are detected by eeze (messages about detected devices show up in
> xsession-errors).

as I do not have eeze_mount, I think that I can't test that. Maybe Mike 
could look at that

Vincent

> Unfortunately I don't know anything about autofoo, otherwise I would
> have sent some patches for 1,2 and 3. If I can do anything else let me know.
>
> Cheers
> Jochen
>
>
> --
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
>
>
> --
> Cedric BAIL
>

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] e_fm build and mount problems

[Vincent Torri]

On Sat, 12 Nov 2011, Vincent Torri wrote:

>
> Hey,
>
> On Sat, 12 Nov 2011, Vincent Torri wrote:
>
>> Hi all,
>>
>> I was trying to dig deeper into a problem where I get a corruption in
>> e_fm when mounting and removing a usb disk (see
>> here:http://marc.info/?l=enlightenment-devel&m=132014458110340&w=2 for
>> details). I found a couple of problems when trying to build e with
>> different e_fm options.
>>
>> 1. when efl is installed in /opt/ for example eeze_mount is always
>> disabled because the configure test fails because of a missing
>> -L/opt/e17 in the compile.
>
> i don't have libmount, so I can't test it. Can you paste config.log of
> eeze, please ?
>
>>
>> 2. configure help says enable hal device backend is disabled by default,
>> however I always have it enabled after configure
>
> there is indeed a problem with hal device *backend* (which is actually not
> disabled by default), but the variable e_cv_want_device_hal is anyway not
> used at all. So I'm wondering why that part of code is still in
> configure.ac
>
> hal *mount* is enabled by default, and that's what is displayed in the
> configure output:
>
> Preferred Backends:
>  * device..: eeze
>  * hal_mount...: enabled
>  * udisks_mount: enabled
>  * eeze_mount..:
>
> I think i've fixed that in svn. Tell me if there's something wrong.
>
>> 3. when I pass --disable-mount-hal to configure the build of
>> e_fm_main_udisks fails with the following error:
>>
>> /usr/bin/ld: e_fm_main_udisks.o: undefined reference to symbol
>> 'e_dbus_method_call_send'
>> /usr/bin/ld: note: 'e_dbus_method_call_send' is defined in DSO

try the patch below:

Index: configure.ac
===
--- configure.ac(revision 65096)
+++ configure.ac(working copy)
@@ -462,6 +462,7 @@
  ecore-ipc >= 1.0.999 \
  eet >= 1.4.0 \
  efreet >= 1.0.999 \
+edbus >= 1.0.999 \
  eina >= 1.0.999"
  efm_requires+=" $eeze_mount $dbus_mount $hal_mount $udisks_mount"


Vincent

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E17 tablet recommendation / Android

[Jeff Hoogland]

Do NOT get ArchOS if you want fully working hardware. In fact with it's
current state I would not recommend ARM anything - as someone who has been
working to stick Debian/Ubuntu with E17 over Android installs it is hard
work that is almost never fully functional. Check out my youtube channel
for some good videos of E on various tablets:

http://www.youtube.com/user/Jeffhoogland?feature=mhee

On Sat, Nov 12, 2011 at 12:55 AM, Jérémy Zurcher  wrote:

> On Friday 11 November 2011  09:31, Vincent Torri wrote :
> >
> >
> > On Fri, 11 Nov 2011, Andreas Volz wrote:
> >
> > > Hello,
> > >
> > > could anyone recommend a good tablet pc for E17?
> I've deployed a few acer iconia + debian wheezy
> >
> > maybe archos
> >
> > > Does anyone know if it's possible to run edje based applications
> > > (not E17 itself!) on Android based tablets? As Android supports native
> > > applications and has an OpenGL interface it should be possible, not?
> >
> > ask chidambar, he is working in the Archos company
> >
> > Vincent
> >
> >
> --
> > RSA(R) Conference 2012
> > Save $700 by Nov 18
> > Register now
> > http://p.sf.net/sfu/rsa-sfdev2dev1
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> >
> >
> >
>
> !DSPAM:4ebe18783366824242105!
>
>
>
>
> --
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>



-- 
~Jeff Hoogland 
Thoughts on Technology , Tech Blog
Bodhi Linux , Enlightenment for your Desktop
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

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

[David Seikel]

On Sat, 12 Nov 2011 06:33:09 -0800 "Enlightenment SVN"
 wrote:

> Log:
> A few basic docs, just to show the sort of structure I'm aiming for.
>   
>   I don't know doxygen, and doxygen don't seem to quite understand
> what I want. Which is to document the lua side of things, but having
> the docs near the C functions that define them.  Help me out please
> doxygen experts. 
>   Note the problem with edje:rect().
>   
>   Or I could just write one big blob.  E.

I'm putting this up so that people that actually know doxygen can help
me out.

Basically I want to document the lua API itself, not the C code, so
that lua scripters know how to work with it. The lua API is created by
the C code though, so that's where the doc comments go.  Doxygen however
does not understand about creating lua docs from the underlaying C.

I had just reorganised the code to be better for programmers to read.
This does not work well with the doxygen I have in this example
though.  Note how the edje:rect() description is out of place.

So I want to have the doc comments near the C function that implements
any given lua function or "class".  But then I need doxygen to neatly
list the classes, with their functions in a single group.  Preferably
with the inheritance details also mentioned.

Yes, I know that I'll have to manually enter details about function
arguments, return values, etc.  Doxygen wont be able to sort that out.
The question is, how do I convince doxygen to gather things together
and group them nicely on the page?

-- 
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
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

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

[Cedric BAIL]

On Sat, Nov 12, 2011 at 3:48 PM, David Seikel  wrote:
> On Sat, 12 Nov 2011 06:33:09 -0800 "Enlightenment SVN"
>  wrote:
>
>> Log:
>> A few basic docs, just to show the sort of structure I'm aiming for.
>>
>>   I don't know doxygen, and doxygen don't seem to quite understand
>> what I want. Which is to document the lua side of things, but having
>> the docs near the C functions that define them.  Help me out please
>> doxygen experts.
>>   Note the problem with edje:rect().
>>
>>   Or I could just write one big blob.  E.
>
> I'm putting this up so that people that actually know doxygen can help
> me out.
>
> Basically I want to document the lua API itself, not the C code, so
> that lua scripters know how to work with it. The lua API is created by
> the C code though, so that's where the doc comments go.  Doxygen however
> does not understand about creating lua docs from the underlaying C.
>
> I had just reorganised the code to be better for programmers to read.
> This does not work well with the doxygen I have in this example
> though.  Note how the edje:rect() description is out of place.
>
> So I want to have the doc comments near the C function that implements
> any given lua function or "class".  But then I need doxygen to neatly
> list the classes, with their functions in a single group.  Preferably
> with the inheritance details also mentioned.
>
> Yes, I know that I'll have to manually enter details about function
> arguments, return values, etc.  Doxygen wont be able to sort that out.
> The question is, how do I convince doxygen to gather things together
> and group them nicely on the page?

Yop, yop. Did you look at edje_cc_handlers.c ? I think it does with
edcref what you are trying to do for lua.
-- 
Cedric BAIL

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

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

[David Seikel]

On Sat, 12 Nov 2011 16:12:18 +0100 Cedric BAIL 
wrote:

> On Sat, Nov 12, 2011 at 3:48 PM, David Seikel 
> wrote:
> > On Sat, 12 Nov 2011 06:33:09 -0800 "Enlightenment SVN"
> >  wrote:
> >
> >> Log:
> >> A few basic docs, just to show the sort of structure I'm aiming
> >> for.
> >>
> >>   I don't know doxygen, and doxygen don't seem to quite understand
> >> what I want. Which is to document the lua side of things, but
> >> having the docs near the C functions that define them.  Help me
> >> out please doxygen experts.
> >>   Note the problem with edje:rect().
> >>
> >>   Or I could just write one big blob.  E.
> >
> > I'm putting this up so that people that actually know doxygen can
> > help me out.
> >
> > Basically I want to document the lua API itself, not the C code, so
> > that lua scripters know how to work with it. The lua API is created
> > by the C code though, so that's where the doc comments go.  Doxygen
> > however does not understand about creating lua docs from the
> > underlaying C.
> >
> > I had just reorganised the code to be better for programmers to
> > read. This does not work well with the doxygen I have in this
> > example though.  Note how the edje:rect() description is out of
> > place.
> >
> > So I want to have the doc comments near the C function that
> > implements any given lua function or "class".  But then I need
> > doxygen to neatly list the classes, with their functions in a
> > single group.  Preferably with the inheritance details also
> > mentioned.
> >
> > Yes, I know that I'll have to manually enter details about function
> > arguments, return values, etc.  Doxygen wont be able to sort that
> > out. The question is, how do I convince doxygen to gather things
> > together and group them nicely on the page?
> 
> Yop, yop. Did you look at edje_cc_handlers.c ? I think it does with
> edcref what you are trying to do for lua.

I did.  In fact there is similar lua stuff already from the old lua
code, though no examples for me to copy and pull apart.  I could not get
it to work though, but I'll have another poke at it.

-- 
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
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

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

[David Seikel]

On Sun, 13 Nov 2011 01:22:56 +1000 David Seikel 
wrote:

> On Sat, 12 Nov 2011 16:12:18 +0100 Cedric BAIL 
> wrote:
> 
> > On Sat, Nov 12, 2011 at 3:48 PM, David Seikel 
> > wrote:
> > > On Sat, 12 Nov 2011 06:33:09 -0800 "Enlightenment SVN"
> > >  wrote:
> > >
> > >> Log:
> > >> A few basic docs, just to show the sort of structure I'm aiming
> > >> for.
> > >>
> > >>   I don't know doxygen, and doxygen don't seem to quite
> > >> understand what I want. Which is to document the lua side of
> > >> things, but having the docs near the C functions that define
> > >> them.  Help me out please doxygen experts.
> > >>   Note the problem with edje:rect().
> > >>
> > >>   Or I could just write one big blob.  E.
> > >
> > > I'm putting this up so that people that actually know doxygen can
> > > help me out.
> > >
> > > Basically I want to document the lua API itself, not the C code,
> > > so that lua scripters know how to work with it. The lua API is
> > > created by the C code though, so that's where the doc comments
> > > go.  Doxygen however does not understand about creating lua docs
> > > from the underlaying C.
> > >
> > > I had just reorganised the code to be better for programmers to
> > > read. This does not work well with the doxygen I have in this
> > > example though.  Note how the edje:rect() description is out of
> > > place.
> > >
> > > So I want to have the doc comments near the C function that
> > > implements any given lua function or "class".  But then I need
> > > doxygen to neatly list the classes, with their functions in a
> > > single group.  Preferably with the inheritance details also
> > > mentioned.
> > >
> > > Yes, I know that I'll have to manually enter details about
> > > function arguments, return values, etc.  Doxygen wont be able to
> > > sort that out. The question is, how do I convince doxygen to
> > > gather things together and group them nicely on the page?
> > 
> > Yop, yop. Did you look at edje_cc_handlers.c ? I think it does with
> > edcref what you are trying to do for lua.
> 
> I did.  In fact there is similar lua stuff already from the old lua
> code, though no examples for me to copy and pull apart.  I could not
> get it to work though, but I'll have another poke at it.

Hmm, I think that's still linear.  I can't see how that pulls bits from
all over the file and collects them into one group.

I'm off to bed, might understand it more after sleep.

-- 
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
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

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

[Vincent Torri]

On Sun, 13 Nov 2011, David Seikel wrote:


On Sun, 13 Nov 2011 01:22:56 +1000 David Seikel 
wrote:


On Sat, 12 Nov 2011 16:12:18 +0100 Cedric BAIL 
wrote:


On Sat, Nov 12, 2011 at 3:48 PM, David Seikel 
wrote:

On Sat, 12 Nov 2011 06:33:09 -0800 "Enlightenment SVN"
 wrote:


Log:
A few basic docs, just to show the sort of structure I'm aiming
for.

  I don't know doxygen, and doxygen don't seem to quite
understand what I want. Which is to document the lua side of
things, but having the docs near the C functions that define
them.  Help me out please doxygen experts.
  Note the problem with edje:rect().

  Or I could just write one big blob.  E.


I'm putting this up so that people that actually know doxygen can
help me out.

Basically I want to document the lua API itself, not the C code,
so that lua scripters know how to work with it. The lua API is
created by the C code though, so that's where the doc comments
go.  Doxygen however does not understand about creating lua docs
from the underlaying C.

I had just reorganised the code to be better for programmers to
read. This does not work well with the doxygen I have in this
example though.  Note how the edje:rect() description is out of
place.

So I want to have the doc comments near the C function that
implements any given lua function or "class".  But then I need
doxygen to neatly list the classes, with their functions in a
single group.  Preferably with the inheritance details also
mentioned.

Yes, I know that I'll have to manually enter details about
function arguments, return values, etc.  Doxygen wont be able to
sort that out. The question is, how do I convince doxygen to
gather things together and group them nicely on the page?


Yop, yop. Did you look at edje_cc_handlers.c ? I think it does with
edcref what you are trying to do for lua.


I did.  In fact there is similar lua stuff already from the old lua
code, though no examples for me to copy and pull apart.  I could not
get it to work though, but I'll have another poke at it.


Hmm, I think that's still linear.  I can't see how that pulls bits from
all over the file and collects them into one group.

I'm off to bed, might understand it more after sleep.


try:

/**
 * @addtogroup My_Lua_Group My Lua group
 *
 * @{
 */

add your documentation. That documentation will be in the "My_Lua_Group" 
group



/**
 * @}
 */

Vincent--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] About release, snapshots and openBSD port

[Jonathan Armani]

Yep, enough word have been said, I'm not interested in pushing diff /
process anymore.

End of topic.

On Sat, Nov 12, 2011 at 4:11 AM, Carsten Haitzler  wrote:
> On Fri, 11 Nov 2011 21:43:37 -0500 Youness Alaoui
>  said:
>
>> I don't need to read that (and I have better things to do than fight an
>> endless war on who is right).
>
> then this ends this topic. if you don't want to look at the facts, there is no
> point in this discussion. there is nothing to talk about with you.
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)    ras...@rasterman.com
>
>
> --
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] About release, snapshots and openBSD port

[Vincent Torri]

On Sat, 12 Nov 2011, Jonathan Armani wrote:


Yep, enough word have been said, I'm not interested in pushing diff /
process anymore.


raster, Jonathan was enthousiastic in porting e17 on OpenBSD. Now, if he 
is still interested in using e17 (that's even not sure anymore), he will 
just keep his patch privately, which is BAD.


I try to be nice and polite, to talk about the EFL, e17, to attract 
people so that they join our forces (and yes, i have really attracted new 
people in IRC channels !). Now, you're repulsing them ! Fuck ! Just for 
some patches that are not correctly written, you just upset people.


Instead of saying more or less "your patches suck, we don't want them", 
why not saying "hmm these patches are not good, because etc.. can you 
please rewrite them that way ?" Is it too much for you, to be a bit polite 
???


Also, to be clear, I contact you on IRC about the private discussion I had 
with Jonathan, talking to you about those patches. I clearly said that 
some patches can be committed as-is, and some don't. I have warned you !!


Now, I understand a bit more how I have to do the work : I don't talk to 
you about stuff I know you won't be interested in (if you were 
interesting in OpenBSD port, you won't have overreact like that). I'll do 
it myself (like I did before I talked to you about those patches, it was 
working nicely), talking privately to people, so that we could move on.


I'm really really upset to see all my "behind the scene" work to attract 
people destroyed, and to finally see that you make them leave to project.


No need to answer to that mail. I won't read your answer. I don't want to 
spend endless time answering for nothing.


Vincent



End of topic.

On Sat, Nov 12, 2011 at 4:11 AM, Carsten Haitzler  wrote:

On Fri, 11 Nov 2011 21:43:37 -0500 Youness Alaoui
 said:


I don't need to read that (and I have better things to do than fight an
endless war on who is right).


then this ends this topic. if you don't want to look at the facts, there is no
point in this discussion. there is nothing to talk about with you.

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


--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] About release, snapshots and openBSD port

[Gustavo Sverzut Barbieri]

On Sat, Nov 12, 2011 at 3:19 PM, Vincent Torri  wrote:
> On Sat, 12 Nov 2011, Jonathan Armani wrote:
>
>> Yep, enough word have been said, I'm not interested in pushing diff /
>> process anymore.

:-(

> raster, Jonathan was enthousiastic in porting e17 on OpenBSD. Now, if he is 
> still interested in using e17 (that's even not sure anymore), he will just 
> keep his patch privately, which is BAD.
>
> I try to be nice and polite, to talk about the EFL, e17, to attract people so 
> that they join our forces (and yes, i have really attracted new people in IRC 
> channels !). Now, you're repulsing them ! Fuck ! Just for some patches that 
> are not correctly written, you just upset people.
>
> Instead of saying more or less "your patches suck, we don't want them", why 
> not saying "hmm these patches are not good, because etc.. can you please 
> rewrite them that way ?" Is it too much for you, to be a bit polite ???
>
> Also, to be clear, I contact you on IRC about the private discussion I had 
> with Jonathan, talking to you about those patches. I clearly said that some 
> patches can be committed as-is, and some don't. I have warned you !!
>
> Now, I understand a bit more how I have to do the work : I don't talk to you 
> about stuff I know you won't be interested in (if you were interesting in 
> OpenBSD port, you won't have overreact like that). I'll do it myself (like I 
> did before I talked to you about those patches, it was working nicely), 
> talking privately to people, so that we could move on.
>
> I'm really really upset to see all my "behind the scene" work to attract 
> people destroyed, and to finally see that you make them leave to project.
>
> No need to answer to that mail. I won't read your answer. I don't want to 
> spend endless time answering for nothing.

+1 for Vincent's mail.

Raster, please try to improve your personal skills. Your attitude will
get us nowhere.

And to be fair, if we apply this same attitude to everyone, your
Edje-multisense patch would never get in. But it got, even tho people
kindly asked you to remove it. You didn't.  That's all right, but then
do not act like that with Jonathan.

See why "releases won't get us more developers?" Just being close to
one (even close being undefined), we got one guy investing his spare
time to help -> THIS IS HELP BROUGHT BY RELEASE. But even before the
release we already scared him away :-(


Jonathan, if there is still time, please reconsider your decision and
keep working with us. Fortunately this project is not just about
raster. If Vincent says he'll help you, he will do and Raster has
nothing to do with it. If you need something feel free to ping me at
IRC (k-s).

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

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

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

[David Seikel]

On Sat, 12 Nov 2011 16:40:02 +0100 (CET) Vincent Torri
 wrote:

> 
> On Sun, 13 Nov 2011, David Seikel wrote:
> 
> > On Sun, 13 Nov 2011 01:22:56 +1000 David Seikel 
> > wrote:
> >
> >> On Sat, 12 Nov 2011 16:12:18 +0100 Cedric BAIL
> >>  wrote:
> >>
> >>> On Sat, Nov 12, 2011 at 3:48 PM, David Seikel 
> >>> wrote:
>  On Sat, 12 Nov 2011 06:33:09 -0800 "Enlightenment SVN"
>   wrote:
> 
> > Log:
> > A few basic docs, just to show the sort of structure I'm aiming
> > for.
> >
> >   I don't know doxygen, and doxygen don't seem to quite
> > understand what I want. Which is to document the lua side of
> > things, but having the docs near the C functions that define
> > them.  Help me out please doxygen experts.
> >   Note the problem with edje:rect().
> >
> >   Or I could just write one big blob.  E.
> 
>  I'm putting this up so that people that actually know doxygen can
>  help me out.
> 
>  Basically I want to document the lua API itself, not the C code,
>  so that lua scripters know how to work with it. The lua API is
>  created by the C code though, so that's where the doc comments
>  go.  Doxygen however does not understand about creating lua docs
>  from the underlaying C.
> 
>  I had just reorganised the code to be better for programmers to
>  read. This does not work well with the doxygen I have in this
>  example though.  Note how the edje:rect() description is out of
>  place.
> 
>  So I want to have the doc comments near the C function that
>  implements any given lua function or "class".  But then I need
>  doxygen to neatly list the classes, with their functions in a
>  single group.  Preferably with the inheritance details also
>  mentioned.
> 
>  Yes, I know that I'll have to manually enter details about
>  function arguments, return values, etc.  Doxygen wont be able to
>  sort that out. The question is, how do I convince doxygen to
>  gather things together and group them nicely on the page?
> >>>
> >>> Yop, yop. Did you look at edje_cc_handlers.c ? I think it does
> >>> with edcref what you are trying to do for lua.
> >>
> >> I did.  In fact there is similar lua stuff already from the old lua
> >> code, though no examples for me to copy and pull apart.  I could
> >> not get it to work though, but I'll have another poke at it.
> >
> > Hmm, I think that's still linear.  I can't see how that pulls bits
> > from all over the file and collects them into one group.
> >
> > I'm off to bed, might understand it more after sleep.
> 
> try:
> 
> /**
>   * @addtogroup My_Lua_Group My Lua group
>   *
>   * @{
>   */
> 
> add your documentation. That documentation will be in the
> "My_Lua_Group" group
> 
> 
> /**
>   * @}
>   */

Meh, could not sleep.

That still is not pulling together the scattered parts of the group.
Unless I'm still doing something wrong.  The edje_cc_handlers.c stuff
seems more concerned with formatting than consolidating bits.

Perhaps it has something to do with the fact that looking at the
results locally seems to not pick up the css?

Just to make it more clear, say I have C code that defines a lua
structure in this order -

class A
   function A:foo()
   function A:bar()

class B
   function B:baz()

   function A:baz_frobber()

To make things easier for the developer, all things to do with baz are
together in the source code, even if it's from different classes.
Which means that bits of class A are scattered through the code.
Doxygen does not actually understand that the C code is defining such a
structure.  But I want the doxygen to pull together the scattered bits
of class A into one spot and document it as -

class A
   function A:foo()
   function A:bar()
   function A:baz_frobber()

class B
   function B:baz()

I can see that I might just have to rearrange the code to keep doxygen
happy, so long as the compiler is also happy.  Arranging the code to
make the developers happy comes in a poor third.  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
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

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

[David Seikel]

On Sun, 13 Nov 2011 03:56:47 +1000 David Seikel 
wrote:

> On Sat, 12 Nov 2011 16:40:02 +0100 (CET) Vincent Torri
>  wrote:
> 
> > 
> > On Sun, 13 Nov 2011, David Seikel wrote:
> > 
> > > On Sun, 13 Nov 2011 01:22:56 +1000 David Seikel
> > >  wrote:
> > >
> > >> On Sat, 12 Nov 2011 16:12:18 +0100 Cedric BAIL
> > >>  wrote:
> > >>
> > >>> On Sat, Nov 12, 2011 at 3:48 PM, David Seikel
> > >>>  wrote:
> >  On Sat, 12 Nov 2011 06:33:09 -0800 "Enlightenment SVN"
> >   wrote:
> > 
> > > Log:
> > > A few basic docs, just to show the sort of structure I'm
> > > aiming for.
> > >
> > >   I don't know doxygen, and doxygen don't seem to quite
> > > understand what I want. Which is to document the lua side of
> > > things, but having the docs near the C functions that define
> > > them.  Help me out please doxygen experts.
> > >   Note the problem with edje:rect().
> > >
> > >   Or I could just write one big blob.  E.
> > 
> >  I'm putting this up so that people that actually know doxygen
> >  can help me out.
> > 
> >  Basically I want to document the lua API itself, not the C
> >  code, so that lua scripters know how to work with it. The lua
> >  API is created by the C code though, so that's where the doc
> >  comments go.  Doxygen however does not understand about
> >  creating lua docs from the underlaying C.
> > 
> >  I had just reorganised the code to be better for programmers to
> >  read. This does not work well with the doxygen I have in this
> >  example though.  Note how the edje:rect() description is out of
> >  place.
> > 
> >  So I want to have the doc comments near the C function that
> >  implements any given lua function or "class".  But then I need
> >  doxygen to neatly list the classes, with their functions in a
> >  single group.  Preferably with the inheritance details also
> >  mentioned.
> > 
> >  Yes, I know that I'll have to manually enter details about
> >  function arguments, return values, etc.  Doxygen wont be able
> >  to sort that out. The question is, how do I convince doxygen to
> >  gather things together and group them nicely on the page?
> > >>>
> > >>> Yop, yop. Did you look at edje_cc_handlers.c ? I think it does
> > >>> with edcref what you are trying to do for lua.
> > >>
> > >> I did.  In fact there is similar lua stuff already from the old
> > >> lua code, though no examples for me to copy and pull apart.  I
> > >> could not get it to work though, but I'll have another poke at
> > >> it.
> > >
> > > Hmm, I think that's still linear.  I can't see how that pulls bits
> > > from all over the file and collects them into one group.
> > >
> > > I'm off to bed, might understand it more after sleep.
> > 
> > try:
> > 
> > /**
> >   * @addtogroup My_Lua_Group My Lua group
> >   *
> >   * @{
> >   */
> > 
> > add your documentation. That documentation will be in the
> > "My_Lua_Group" group
> > 
> > 
> > /**
> >   * @}
> >   */
> 
> Meh, could not sleep.
> 
> That still is not pulling together the scattered parts of the group.
> Unless I'm still doing something wrong.  The edje_cc_handlers.c stuff
> seems more concerned with formatting than consolidating bits.
> 
> Perhaps it has something to do with the fact that looking at the
> results locally seems to not pick up the css?
> 
> Just to make it more clear, say I have C code that defines a lua
> structure in this order -
> 
> class A
>function A:foo()
>function A:bar()
> 
> class B
>function B:baz()
> 
>function A:baz_frobber()
> 
> To make things easier for the developer, all things to do with baz are
> together in the source code, even if it's from different classes.
> Which means that bits of class A are scattered through the code.
> Doxygen does not actually understand that the C code is defining such
> a structure.  But I want the doxygen to pull together the scattered
> bits of class A into one spot and document it as -
> 
> class A
>function A:foo()
>function A:bar()
>function A:baz_frobber()
> 
> class B
>function B:baz()
> 
> I can see that I might just have to rearrange the code to keep doxygen
> happy, so long as the compiler is also happy.  Arranging the code to
> make the developers happy comes in a poor third.  B-(

http://sourceforge.net/projects/doxygen/forums/forum/130994/topic/4741651

Doxygen pretty much sucks at this.  sigh

/me rearranges the source code, so I can at least get on with the damn
documentation.  lol

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


signature.asc
Description: PGP signature
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
enlightenment-devel mailing list
enlightenm

[E-devel] Fwd: About release, snapshots and openBSD port

[Youness Alaoui]

On Fri, Nov 11, 2011 at 10:26 PM, Carsten Haitzler wrote:

> On Fri, 11 Nov 2011 21:49:46 -0500 Youness Alaoui
>  said:
>
> WE were asked to generate the tarballs. WE... not him. if he wants
> tarballs he
> can make them himself. i would never have said no. i can't and won't stop
> him -
> he can make the tarballs all he likes! but WE were asked to make them. that
> means one of us - presumably me, has to generate them UPLOAD them and then
> TELL
> SOMEONE they are uploaded and exist! if HE wants tarballs and wants to
> build
> them himself.. absolutely. go ahead! by all means! he can also just use
> make
> dist which is simpler. but that isn't what was asked for.
>

1 - read what I wrote, I said that for now he used the script, until the
script gets put on a server on which I don't have access
2 - why "presumably me" ?


>
> > I haven't proven your point, I don't see where I did. On the contrary, I
> > proved that you can create a simple script that does it. Who asked for
> any
> > announcements? who even asked for uploads? The guy used my script to
> > generate the tarballs from svn on his own machine and then used the
> > tarballs in his build system and was happy about it. Ideally, the script
> > should run on a server in a cron job and copy the files to a publically
> > available directory, I'm not uploading the files because I don't have
> > access to such server. But that is outside the scope of what was asked, I
> > helped him get what he wanted, he's happy about it, he'll continue
> porting
> > to BSD or whatever he wants to do with it. In the end, we didn't lose a
> > contributor, and that's the final goal that was reached (who btw said
> that
> > he got demotivated after talking to you because of the way you spoke).
> > Of course, it's less useful than a make distcheck, that's why an actual
> > build system would be needed for continuous integration checks, but that
> is
> > besides the point. They wanted a tarball, I provided a tarball, nothing
> > more, nothing less.
> > Stop assuming what the other person wants, and then make judgment calls
> on
> > what you think they may or may not want. That's not how you can build
> your
> > community, by closing all doors in the face of everyone who wants to
> help.
>
> dude... did you READ AT ALL WHAT VTORRI ASKED FOR? my god! you really want
> to
> just run around with your opinions without ever reading the facts. they
> asked
> to HAVE daily snapshots. they aren't asking how THEY can do it themselves.
> they
> are asking for them to BE done for them. you OFFERED an alternative.
>
> man - YOU demotivate ME. your snide comments, grandstanding on your soapbox
> without ever bothering to READ the discussion or facts at hand - which you
> very
> clearly didn't bother to read, or your understanding of english is not so
> great. when someone asks to have snapshots - they ask for tarballs, which
> need
> to be generated and uploaded. we can generate them on the server, but a
> cron
> job is no better than a random svn checkout done by them. if you READ the
> emails and READ the irc discussion you might have the facts.
>
> on email i asked what's so hard about svn. on irc i got the response that
> they
> have no idea when to svn checkout because they don't know if it works or
> not.
> put that together with a cron job either done by them OR us is the same
> thing.
> nothing has improved.
>
> pointless email as you're simply not reading the actual content.
>
you don't seem to read what I wrote, you ignore the facts.. the facts are
not the commits or how bad they were, the facts were your attitude and
condescending bullshit. but yeah,you don't seem to be able to acknowledge
that, since you're perfect and everyone else is wrong.

Thank you Vincent and Gustavo for sharing your concerns about this, and
it's too sad that the new contributor has become another victim of raster's
poor social skills. That's what I wanted to avoid, that's what I wanted
raster to understand, and I was hoping for him to reply with something like
"sorry if I offended you, that wasn't my purpose" and that's it, the guy
stays with us, but I guess raster has too much pride and is too
self-centered to recognize his own faults.
I think I will follow Vincent's advice and not reply to this thread
anymore, raster clearly showed he has no comprehension of what people are
trying to tell him here, so this is just an endless drama with no possible
resolution.



>
> > On Fri, Nov 11, 2011 at 8:30 PM, Carsten Haitzler  >wrote:
> >
> > > On Fri, 11 Nov 2011 15:55:46 -0500 Youness Alaoui
> > >  said:
> > >
> > > so you've basically proven my point - it's the same as an svn
> checkout...
> > > and
> > > that script still doesn't upload them, or make any announcement that
> they
> > > have
> > > been created. it's actually less useful than make distc (or distcheck)
> and
> > > much
> > > longer. there is no quality checking there... and which point it's
> > > busywork.
> > >
> > > > Here, I just wrote a sc

[E-devel] 'elm/scrolled_entry' not registered

[Andreas Volz]

Hello,

some time ago I created an edje file for my application with externals.

Now the entry is not visible and this error is printed:

ERR<9322>:edje edje_external.c:378 _edje_external_type_add() external
type 'elm/scrolled_entry' not registered

I deleted the entry with editje and added it later, but nothing changes.

Is editje not fitting to latest elementary?

regards
Andreas

-- 
Technical Blog 

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] 'elm/scrolled_entry' not registered

[Gustavo Sverzut Barbieri]

On Sat, Nov 12, 2011 at 8:43 PM, Andreas Volz  wrote:
> Hello,
>
> some time ago I created an edje file for my application with externals.
>
> Now the entry is not visible and this error is printed:
>
> ERR<9322>:edje edje_external.c:378 _edje_external_type_add() external
> type 'elm/scrolled_entry' not registered
>
> I deleted the entry with editje and added it later, but nothing changes.
>
> Is editje not fitting to latest elementary?

there is no elm_scrolled_entry anymore, you must use elm_entry instead.

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

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: jeffdameth trunk/e/src/modules/everything

[Gustavo Sverzut Barbieri]

On Sat, Nov 12, 2011 at 10:36 PM, Enlightenment SVN
 wrote:
> Log:
> e17/evry: what a hack :)

thanks ;-)


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

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Fwd: About release, snapshots and openBSD port

[Stefan Schmidt]

Hello.

I have not joined any of these flame wares before as I don't think to
change anything significant but only start to hurt peoples feelings
for each other. But I had to join here as it started to look like a
witch hunt on raster here. Please take a moment when reading this.
Thanks for your time.

On Sat, 2011-11-12 at 13:43, Youness Alaoui wrote:
>
> you don't seem to read what I wrote, you ignore the facts.. the facts are
> not the commits or how bad they were, the facts were your attitude and
> condescending bullshit. but yeah,you don't seem to be able to acknowledge
> that, since you're perfect and everyone else is wrong.

Great, personal insults are getting us really forward here. This is
one of the social skills you are calling here for. Discussing with
others without getting into personal insults. Given this mail and the
long rant where you "behaved like a dick" (citation from you) are
letting me wonder if you are able to call others for things you do not
handle very well on your own. Something to thing about.

> Thank you Vincent and Gustavo for sharing your concerns about this, and
> it's too sad that the new contributor has become another victim of raster's
> poor social skills. That's what I wanted to avoid, that's what I wanted
> raster to understand, and I was hoping for him to reply with something like
> "sorry if I offended you, that wasn't my purpose" and that's it, the guy
> stays with us, but I guess raster has too much pride and is too
> self-centered to recognize his own faults.

And you wanted that to happen by forcing him into a corner?

That is almost always the best recipe to get the opposite of what you
wanted. Forcing people trigger over reactions from them. Self
protection, naturally for humans. Changing the behaviour of people is
a long and exhausting  process. Nothing you can do by sending of
several mails. And before people even accept what they here from
others they need to respect them. Respect them for their doings and
ideas they have come up with over time. Again nothing you can achieve
in some weeks.

> I think I will follow Vincent's advice and not reply to this thread
> anymore, raster clearly showed he has no comprehension of what people are
> trying to tell him here, so this is just an endless drama with no possible
> resolution.

Black and white thinking all around. Sadly we live in a grey world.
Nothing is only black or only white. Lets have a look at what problems
we have here and what possible solutions we can come up with. (That
what we should aim for in the end, a solution bringing the project
forward).

Raster is stressed out. Short on time and running at the edge of what
is possible for him all the time. Thats a fact and on of the biggest
problems here. Stress calls out on people making hard decisions and
one of this is being brusque to others. I have observed this a lot at
myself when being in stressful times. Family and friends had the
pleasure to get me in such a mood. And even after I recognized this
at myself (the first step, you know), it is very hard to change at
all. Again, behaviour changes are the hardest.

The work part of raster stress we can't influence much. He has to
handle this on its own. And I personally hope that he realizes how
near he comes a actual burnout if he keeps going like this for more
months.

But now to the things we can change. You and Gustavo are trying to
change this project in a direction that should be more welcoming for
developers and users. Making the community grow. I welcome this move,
but doing something like this can not happen by bringing everything
down that happened so far. Raster brought this all to the point what
we have today. Motivating people on the road and de-motivating people
on the road. Again, very natural as we don't live in flower-power
land. :)

So to change to bring in change to this community you need to earn the
respect of the other developers here before steering the way forward.
Bluntly speaking nobody wants to accept orders from people he does not
respect or being paid by. And even the last part may be very hard
sometimes. ;)

For the matters at hand the following could be done:

o Tarballs: Everyone seem to speak about daily tarballs. What I read
  from the openbsd guys have not been daily tarballs but tarballs for
  an alpha or rc to check if everything is fine beofre the actual
  release. Such tarballs are fine and have already been acknowledged
  and done before. They will even get some QA. And QA is something
  that differs from daily tarballs, like your script or a simple make
  disctheck, will produce. SOLUTION: Wait for the alpha and rc
  tarballs.

o OpenBSD patches: Vincent asked raster to have a look at the patches.
  He did look and pointed out what was wrong. Agreed, a bit to blunt
  maybe. He did mention better options though. Something that people
  like to ignore in this thread. (BSD specific malloc changes in
  mempool instead on every file using it, not changing API/ABI with

Re: [E-devel] E SVN: barbieri IN trunk: . E-MODULES-EXTRA/quickaccess/src PROTO

[Stefan Schmidt]

Hello.

On Sat, 2011-11-12 at 15:02, Enlightenment SVN wrote:
> Log:
> evil is now promoted! Not proto anymore.
>   
>   Doing this for Vincent as he doesn't have the whole SVN trunk checkout.
>   
> 
> Author:   barbieri
> Date: 2011-11-12 15:02:14 -0800 (Sat, 12 Nov 2011)
> New Revision: 65109
> Trac: http://trac.enlightenment.org/e/changeset/65109
> 
> Added:
>   trunk/evil/ 
> Removed:
>   trunk/PROTO/evil/ 
> Modified:
>   trunk/E-MODULES-EXTRA/quickaccess/src/e_mod_main.c 
> trunk/E-MODULES-EXTRA/quickaccess/src/e_mod_main.h 

Did you intend to push the quickaccess changes as well? Looks not
related to the evil promotion (congrats) to me.

regards
Stefan Schmidt

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk: . E-MODULES-EXTRA/quickaccess/src PROTO

[Gustavo Sverzut Barbieri]

On Sat, Nov 12, 2011 at 11:32 PM, Stefan Schmidt
 wrote:
> Hello.
>
> On Sat, 2011-11-12 at 15:02, Enlightenment SVN wrote:
>> Log:
>> evil is now promoted! Not proto anymore.
>>
>>   Doing this for Vincent as he doesn't have the whole SVN trunk checkout.
>>
>>
>> Author:       barbieri
>> Date:         2011-11-12 15:02:14 -0800 (Sat, 12 Nov 2011)
>> New Revision: 65109
>> Trac:         http://trac.enlightenment.org/e/changeset/65109
>>
>> Added:
>>   trunk/evil/
>> Removed:
>>   trunk/PROTO/evil/
>> Modified:
>>   trunk/E-MODULES-EXTRA/quickaccess/src/e_mod_main.c 
>> trunk/E-MODULES-EXTRA/quickaccess/src/e_mod_main.h
>
> Did you intend to push the quickaccess changes as well? Looks not
> related to the evil promotion (congrats) to me.

sorry, forgot to limit the commit and it got in, but nobody is using
this module and shouldn't harm :-S


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

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Fwd: About release, snapshots and openBSD port

[Mike Blumenkrantz]

On Sun, 13 Nov 2011 02:26:00 +0100
Stefan Schmidt  wrote:

> Hello.
> 
> I have not joined any of these flame wares before as I don't think to
> change anything significant but only start to hurt peoples feelings
> for each other. But I had to join here as it started to look like a
> witch hunt on raster here. Please take a moment when reading this.
> Thanks for your time.
> 
> On Sat, 2011-11-12 at 13:43, Youness Alaoui wrote:
> >
> > you don't seem to read what I wrote, you ignore the facts.. the facts are
> > not the commits or how bad they were, the facts were your attitude and
> > condescending bullshit. but yeah,you don't seem to be able to acknowledge
> > that, since you're perfect and everyone else is wrong.
> 
> Great, personal insults are getting us really forward here. This is
> one of the social skills you are calling here for. Discussing with
> others without getting into personal insults. Given this mail and the
> long rant where you "behaved like a dick" (citation from you) are
> letting me wonder if you are able to call others for things you do not
> handle very well on your own. Something to thing about.
> 
> > Thank you Vincent and Gustavo for sharing your concerns about this, and
> > it's too sad that the new contributor has become another victim of raster's
> > poor social skills. That's what I wanted to avoid, that's what I wanted
> > raster to understand, and I was hoping for him to reply with something like
> > "sorry if I offended you, that wasn't my purpose" and that's it, the guy
> > stays with us, but I guess raster has too much pride and is too
> > self-centered to recognize his own faults.
> 
> And you wanted that to happen by forcing him into a corner?
> 
> That is almost always the best recipe to get the opposite of what you
> wanted. Forcing people trigger over reactions from them. Self
> protection, naturally for humans. Changing the behaviour of people is
> a long and exhausting  process. Nothing you can do by sending of
> several mails. And before people even accept what they here from
> others they need to respect them. Respect them for their doings and
> ideas they have come up with over time. Again nothing you can achieve
> in some weeks.
> 
> > I think I will follow Vincent's advice and not reply to this thread
> > anymore, raster clearly showed he has no comprehension of what people are
> > trying to tell him here, so this is just an endless drama with no possible
> > resolution.
> 
> Black and white thinking all around. Sadly we live in a grey world.
> Nothing is only black or only white. Lets have a look at what problems
> we have here and what possible solutions we can come up with. (That
> what we should aim for in the end, a solution bringing the project
> forward).
> 
> Raster is stressed out. Short on time and running at the edge of what
> is possible for him all the time. Thats a fact and on of the biggest
> problems here. Stress calls out on people making hard decisions and
> one of this is being brusque to others. I have observed this a lot at
> myself when being in stressful times. Family and friends had the
> pleasure to get me in such a mood. And even after I recognized this
> at myself (the first step, you know), it is very hard to change at
> all. Again, behaviour changes are the hardest.
> 
> The work part of raster stress we can't influence much. He has to
> handle this on its own. And I personally hope that he realizes how
> near he comes a actual burnout if he keeps going like this for more
> months.
> 
> But now to the things we can change. You and Gustavo are trying to
> change this project in a direction that should be more welcoming for
> developers and users. Making the community grow. I welcome this move,
> but doing something like this can not happen by bringing everything
> down that happened so far. Raster brought this all to the point what
> we have today. Motivating people on the road and de-motivating people
> on the road. Again, very natural as we don't live in flower-power
> land. :)
> 
> So to change to bring in change to this community you need to earn the
> respect of the other developers here before steering the way forward.
> Bluntly speaking nobody wants to accept orders from people he does not
> respect or being paid by. And even the last part may be very hard
> sometimes. ;)
> 
> For the matters at hand the following could be done:
> 
> o Tarballs: Everyone seem to speak about daily tarballs. What I read
>   from the openbsd guys have not been daily tarballs but tarballs for
>   an alpha or rc to check if everything is fine beofre the actual
>   release. Such tarballs are fine and have already been acknowledged
>   and done before. They will even get some QA. And QA is something
>   that differs from daily tarballs, like your script or a simple make
>   disctheck, will produce. SOLUTION: Wait for the alpha and rc
>   tarballs.
> 
> o OpenBSD patches: Vincent asked raster to have a look at the patches.
>   He did look and point

Re: [E-devel] E SVN: barbieri IN trunk/THEMES/detourious: bits images

[hannes.janet...@gmail.com]

On Sat, Nov 12, 2011 at 7:17 PM, Enlightenment SVN
 wrote:
> Log:
> THEMES/detorious: subtle fade of menu separator endings.
>
>  This is less boring than the old one that looked like Windows95 :-)
>
not really liking this one. the full width menu separator is a really
distinguishing feature to me. was hard to get this working in gtk-2.0
and impossible in gtk-3.0 so far.

http://www.khohar.com/it/hardware/image027.jpg see the difference?

>
>
> Author:       barbieri
> Date:         2011-11-12 10:17:52 -0800 (Sat, 12 Nov 2011)
> New Revision: 65098
> Trac:         http://trac.enlightenment.org/e/changeset/65098
>
> Modified:
>  trunk/THEMES/detourious/bits/menu.edc 
> trunk/THEMES/detourious/images/menu_im1.png
>
> Modified: trunk/THEMES/detourious/bits/menu.edc
> ===
> --- trunk/THEMES/detourious/bits/menu.edc       2011-11-12 14:33:08 UTC (rev 
> 65097)
> +++ trunk/THEMES/detourious/bits/menu.edc       2011-11-12 18:17:52 UTC (rev 
> 65098)
> @@ -192,7 +192,7 @@
>                        mouse_events: 0;
>                        description {
>                                state: "default" 0.0;
> -                               min: 20 2;
> +                               min: 40 2;
>                                max:  2;
>                                rel1 {
>                                        relative: 0.0 0.0;
> @@ -204,7 +204,7 @@
>                                }
>                                image {
>                                        normal: "images/menu_im1.png";
> -                                       border: 2 2 1 1;
> +                                       border: 20 20 1 1;
>                                }
>                                color_class: "menu_base";
>                        }
>
> Modified: trunk/THEMES/detourious/images/menu_im1.png
> ===
> (Binary files differ)
>
>
> --
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/THEMES/detourious: bits images

[hannes.janet...@gmail.com]

On Sun, Nov 13, 2011 at 3:40 AM, hannes.janet...@gmail.com
 wrote:
> On Sat, Nov 12, 2011 at 7:17 PM, Enlightenment SVN
>  wrote:
>> Log:
>> THEMES/detorious: subtle fade of menu separator endings.
>>
>>  This is less boring than the old one that looked like Windows95 :-)
>>
> not really liking this one. the full width menu separator is a really
> distinguishing feature to me. was hard to get this working in gtk-2.0
> and impossible in gtk-3.0 so far.
>
> http://www.khohar.com/it/hardware/image027.jpg see the difference?
>
yours is more like win95 :P
>>
>>
>> Author:       barbieri
>> Date:         2011-11-12 10:17:52 -0800 (Sat, 12 Nov 2011)
>> New Revision: 65098
>> Trac:         http://trac.enlightenment.org/e/changeset/65098
>>
>> Modified:
>>  trunk/THEMES/detourious/bits/menu.edc 
>> trunk/THEMES/detourious/images/menu_im1.png
>>
>> Modified: trunk/THEMES/detourious/bits/menu.edc
>> ===
>> --- trunk/THEMES/detourious/bits/menu.edc       2011-11-12 14:33:08 UTC (rev 
>> 65097)
>> +++ trunk/THEMES/detourious/bits/menu.edc       2011-11-12 18:17:52 UTC (rev 
>> 65098)
>> @@ -192,7 +192,7 @@
>>                        mouse_events: 0;
>>                        description {
>>                                state: "default" 0.0;
>> -                               min: 20 2;
>> +                               min: 40 2;
>>                                max:  2;
>>                                rel1 {
>>                                        relative: 0.0 0.0;
>> @@ -204,7 +204,7 @@
>>                                }
>>                                image {
>>                                        normal: "images/menu_im1.png";
>> -                                       border: 2 2 1 1;
>> +                                       border: 20 20 1 1;
>>                                }
>>                                color_class: "menu_base";
>>                        }
>>
>> Modified: trunk/THEMES/detourious/images/menu_im1.png
>> ===
>> (Binary files differ)
>>
>>
>> --
>> RSA(R) Conference 2012
>> Save $700 by Nov 18
>> Register now
>> http://p.sf.net/sfu/rsa-sfdev2dev1
>> ___
>> enlightenment-svn mailing list
>> enlightenment-...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>>
>

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Fwd: About release, snapshots and openBSD port

[Youness Alaoui]

Hi Stefan,

Thank you for this well written and thought out email, I agree with you on
everything you said (even the bits in which you criticize me), so thanks
again for that.
I would just like to add a few explanations, you seem to see me as someone
who barks up at raster and tries to change him by forcing him into a
corner, and you are right to believe that because I guess that's what I
show somehow. However that is and was not my initial intention, so here is
"my story" :
Initially, I've had a few interactions with raster which always seemed to
end up with me feeling bad because of how he talks to me, I kept feeling
almost bullied, but I didn't give it too much attention, I was told by
others not to take it personal as that's just how raster is. My excitement
for the project was getting hit everytime I spoke to raster. I cannot point
out a log and say "this sentence was harsh", it was just the general mood
of the discussions, the way he talks to you makes you feel dumb and he
seems condescending, even if he's trying to be nice. And while I understand
the stress issues you've brought up, I did not take these into
consideration at the time, as all I could see was someone's attitude being
that of a condescending leader who takes charge, is very stubborn, and
doesn't accept any criticism. As a side joke, someone told me that he was
able to change raster's opinion "once", and it was an accomplishment. So I
believe he is stubborn, he sees his designs, his ideas as better than
everyone else's and he understands everything while others cannot
understand what he knows, so when you give a suggestion, he turns it down
in such a way that it feels "I know better, you are stupid, your intellect
cannot begin to grasp the infinite knowledge needed to understand the issue
at hand, so I will tell you what to do and you must accept it".. this is
not what he says, but this is what it feels when you talk to him, and in
the end, he looks arrogant and almost like a bully. I'm not saying that's
who he is, I'm just saying that's what it feels like to others who talk to
him (ie. me in this case).
This attitude made me feel bad a few times and demotivated me, thankfully,
I've had some excellent chats with other devs in #e.fr and the community
there is warm and welcoming and now I usually just hang there instead of
#edevelop.
Now I've seen many people talk the same about raster, many feel the same
way, and many simply tell me not to talk to him, or that we shouldn't
discuss anything with him, and I've seen a lot of 'hate', anger,
disappointment with some of the things he does, but noone seems to just
tell him. One thing I really hate, it's that excuse of "he is like that, so
let him". That sentence pisses me off to no extent and I usually reply with
"he's a pedophile, so let him rape children because that's just how he
is?", it's an extreme counter example, and that's how I always feel when
people have to tiptoe around someone else's defects. If someone is being an
ass, you tell him he's an ass and he must fix himself, you should not have
to endure him just because it's his personality. Everytime, the pedophile
example pops to my mind, and I get frustrated when I see people tiptoeing
around others.
I have a lot of respect for raster, I know his skills and I'm the first to
say that he is a very talented developer. But that talent does not excuse
his behavior, if I feel offended by someone, I will tell them, I will not
keep it to myself just because I respect his programming skills. But either
way, I decided not to confront raster because it is simply not my place to
do so.
Then we've had that discussion about the release, and while I was politely
trying to explain my point of view, I get increasingly pissed at raster
(and his faithful followers) ignoring some of our arguments and
concentrating on the simple "I do not like/want this" but what ticked me
off is when raster, the master of being rude, tells me that I'm the one
being rude because I give my opinion, and he has the audacity of basically
saying my opinion means nothing because I'm not a major contributor (== I'm
not him). I am usually nice and polite, but when someone pisses me off and
I reach a certain threshold (which I admit, is often quite low), I explode,
at which point, there is no limits to what I can say. So when raster yelled
at me and said that I'm rude, I did not accept that so I decided to let him
know what I think of him exactly. He ignored pretty much everything I said
though.
In this specific thread, I did not start the drama (I don't believe I did),
one of the new contributors says he is also pissed at raster for the way he
spoke to him, and I replied to raster basically telling him "hint, hint,
read back what I wrote in anger last time, because you ignored it, but now
maybe you'll realize there was truth in it", at which point he finally
decides to snap at me and start yelling and taking it personal (which he
refrained from doing in the initial outburst ema

Re: [E-devel] E SVN: barbieri IN trunk/THEMES/detourious: bits images

[Gustavo Sverzut Barbieri]

On Sun, Nov 13, 2011 at 12:41 AM, hannes.janet...@gmail.com
 wrote:
> On Sun, Nov 13, 2011 at 3:40 AM, hannes.janet...@gmail.com
>  wrote:
>> On Sat, Nov 12, 2011 at 7:17 PM, Enlightenment SVN
>>  wrote:
>>> Log:
>>> THEMES/detorious: subtle fade of menu separator endings.
>>>
>>>  This is less boring than the old one that looked like Windows95 :-)
>>>
>> not really liking this one. the full width menu separator is a really
>> distinguishing feature to me. was hard to get this working in gtk-2.0
>> and impossible in gtk-3.0 so far.
>>
>> http://www.khohar.com/it/hardware/image027.jpg see the difference?
>>
> yours is more like win95 :P

What you mean? it starts fading around 20px on each side, while win95
is a hard end.  I still think that separators should even be lighter
in color, with more vertical space. Will look nice, I can try it after
I'm done with connman (finishing it right now)


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

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] About release, snapshots and openBSD port

[The Rasterman]

On Sat, 12 Nov 2011 15:41:26 -0200 Gustavo Sverzut Barbieri
 said:

> On Sat, Nov 12, 2011 at 3:19 PM, Vincent Torri  wrote:
> > On Sat, 12 Nov 2011, Jonathan Armani wrote:
> >
> >> Yep, enough word have been said, I'm not interested in pushing diff /
> >> process anymore.
> 
> :-(
> 
> > raster, Jonathan was enthousiastic in porting e17 on OpenBSD. Now, if he is
> > still interested in using e17 (that's even not sure anymore), he will just
> > keep his patch privately, which is BAD.
> >
> > I try to be nice and polite, to talk about the EFL, e17, to attract people
> > so that they join our forces (and yes, i have really attracted new people
> > in IRC channels !). Now, you're repulsing them ! Fuck ! Just for some
> > patches that are not correctly written, you just upset people.
> >
> > Instead of saying more or less "your patches suck, we don't want them", why
> > not saying "hmm these patches are not good, because etc.. can you please
> > rewrite them that way ?" Is it too much for you, to be a bit polite ???
> >
> > Also, to be clear, I contact you on IRC about the private discussion I had
> > with Jonathan, talking to you about those patches. I clearly said that some
> > patches can be committed as-is, and some don't. I have warned you !!
> >
> > Now, I understand a bit more how I have to do the work : I don't talk to
> > you about stuff I know you won't be interested in (if you were interesting
> > in OpenBSD port, you won't have overreact like that). I'll do it myself
> > (like I did before I talked to you about those patches, it was working
> > nicely), talking privately to people, so that we could move on.
> >
> > I'm really really upset to see all my "behind the scene" work to attract
> > people destroyed, and to finally see that you make them leave to project.
> >
> > No need to answer to that mail. I won't read your answer. I don't want to
> > spend endless time answering for nothing.
> 
> +1 for Vincent's mail.
> 
> Raster, please try to improve your personal skills. Your attitude will
> get us nowhere.
> 
> And to be fair, if we apply this same attitude to everyone, your
> Edje-multisense patch would never get in. But it got, even tho people
> kindly asked you to remove it. You didn't.  That's all right, but then
> do not act like that with Jonathan.
> 
> See why "releases won't get us more developers?" Just being close to
> one (even close being undefined), we got one guy investing his spare
> time to help -> THIS IS HELP BROUGHT BY RELEASE. But even before the
> release we already scared him away :-(
> 
> 
> Jonathan, if there is still time, please reconsider your decision and
> keep working with us. Fortunately this project is not just about
> raster. If Vincent says he'll help you, he will do and Raster has
> nothing to do with it. If you need something feel free to ping me at
> IRC (k-s).

did you READ the log? you didn't i assume like everyone else. armani has a very
thin skin and simply got pissed off at someone saying the patches (which many
he didn't even write, but he took offence anyway) were bad.

hell no - i'm not apologizing for something i didn't do. READ THE LOG. i've
read it over now severla times looking for thigns that may be offensive. the
only thing i find is the general tone of "the patches are bad" and with
specific pointers to what is bad and why. that is called review. that's how it
works. read the log!

> Best Regards,
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
> 
> --
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> ___
> 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


--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] About release, snapshots and openBSD port

[The Rasterman]

On Sat, 12 Nov 2011 18:19:01 +0100 (CET) Vincent Torri 
said:

> 
> 
> On Sat, 12 Nov 2011, Jonathan Armani wrote:
> 
> > Yep, enough word have been said, I'm not interested in pushing diff /
> > process anymore.
> 
> raster, Jonathan was enthousiastic in porting e17 on OpenBSD. Now, if he 
> is still interested in using e17 (that's even not sure anymore), he will 
> just keep his patch privately, which is BAD.
> 
> I try to be nice and polite, to talk about the EFL, e17, to attract 
> people so that they join our forces (and yes, i have really attracted new 
> people in IRC channels !). Now, you're repulsing them ! Fuck ! Just for 
> some patches that are not correctly written, you just upset people.

at no point was i rude. i wasn't all lovey-dovey hug the world, but i wasn't
rude. i talked about the patches.

> Instead of saying more or less "your patches suck, we don't want them", 
> why not saying "hmm these patches are not good, because etc.. can you 
> please rewrite them that way ?" Is it too much for you, to be a bit polite 
> ???

that IS WHAT I WROTE. did anyone actually read it? ok - i didn't use "not good"
i used "bad". same thing. the WORST thing i said was "they have to be kicked
for that" - the breaking of api. that means current openbsd packages have
broken api's. mayube "just patch blindly" might have pissed them off... but
it's true - api breaks along which lots of the diffs were busy fixing up in
apps and other libs were done blindly - without looking around wider at the
impact that kind of thing has. "the colro get patch alone is a totally wrong
direction" might have offended.. wow.. buy saying its the totally wrong
direction?...

i have a good memory of what i said.. and i  have a log. point out to me where
exactly i was RUDE. where i called them "idiots" or "fools" or any kind of
deorgatory term. tell me where i said "all their shit stinks" or any such term

that's what armani, and kakaroto are saying i did. i DIDNT.; read the logs. i'm
not apologizing for what i didn't do. if someone takes offense at someone
saying their work is bad - well too bad. that's the reality. they should grow
up and accept it, or give good reasons why the evaluation was wrong. the
evaluation was very specific on specific aspects of the patches. armani did
make a point about the mempool stuff - i pointed out that their patches were
much greater thanneeded

> Also, to be clear, I contact you on IRC about the private discussion I had 
> with Jonathan, talking to you about those patches. I clearly said that 
> some patches can be committed as-is, and some don't. I have warned you !!

you asked me to look at them - that's fine. how am i meant to know exactly
which ones you have already filtered out?

> Now, I understand a bit more how I have to do the work : I don't talk to 
> you about stuff I know you won't be interested in (if you were 
> interesting in OpenBSD port, you won't have overreact like that). I'll do 
> it myself (like I did before I talked to you about those patches, it was 
> working nicely), talking privately to people, so that we could move on.

god - why is everyone twisting this into something it wasn't. i never said
that. if i didn't care i would not have even looked when you asked.

> I'm really really upset to see all my "behind the scene" work to attract 
> people destroyed, and to finally see that you make them leave to project.
> 
> No need to answer to that mail. I won't read your answer. I don't want to 
> spend endless time answering for nothing.
> 
> Vincent

very childish there. but you won't read this will you?

> >
> > End of topic.
> >
> > On Sat, Nov 12, 2011 at 4:11 AM, Carsten Haitzler 
> > wrote:
> >> On Fri, 11 Nov 2011 21:43:37 -0500 Youness Alaoui
> >>  said:
> >>
> >>> I don't need to read that (and I have better things to do than fight an
> >>> endless war on who is right).
> >>
> >> then this ends this topic. if you don't want to look at the facts, there
> >> is no point in this discussion. there is nothing to talk about with you.
> >>
> >> --
> >> - Codito, ergo sum - "I code, therefore I am" --
> >> The Rasterman (Carsten Haitzler)    ras...@rasterman.com
> >>
> >>
> >> --
> >> RSA(R) Conference 2012
> >> Save $700 by Nov 18
> >> Register now
> >> http://p.sf.net/sfu/rsa-sfdev2dev1
> >> ___
> >> enlightenment-devel mailing list
> >> enlightenment-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>
> >
> > --
> > RSA(R) Conference 2012
> > Save $700 by Nov 18
> > Register now
> > http://p.sf.net/sfu/rsa-sfdev2dev1
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlight

Re: [E-devel] Fwd: About release, snapshots and openBSD port

[The Rasterman]

On Sat, 12 Nov 2011 13:43:06 -0500 Youness Alaoui
 said:

1. you provided a script to do something that wasn't asked for - the request was
not to give them a script. it was for us to do it - and you still haven't
acknowledged that that is no better than what they have now, so what is the
point?

2. i'm not apologizing for something i didn't actually do. as you didn't read
the facts and refuse to, your "condescending bullshit" line is in itself
condescending bullshit - you pretend to know what happened when you won't even
look.

> On Fri, Nov 11, 2011 at 10:26 PM, Carsten Haitzler
> wrote:
> 
> > On Fri, 11 Nov 2011 21:49:46 -0500 Youness Alaoui
> >  said:
> >
> > WE were asked to generate the tarballs. WE... not him. if he wants
> > tarballs he
> > can make them himself. i would never have said no. i can't and won't stop
> > him -
> > he can make the tarballs all he likes! but WE were asked to make them. that
> > means one of us - presumably me, has to generate them UPLOAD them and then
> > TELL
> > SOMEONE they are uploaded and exist! if HE wants tarballs and wants to
> > build
> > them himself.. absolutely. go ahead! by all means! he can also just use
> > make
> > dist which is simpler. but that isn't what was asked for.
> >
> 
> 1 - read what I wrote, I said that for now he used the script, until the
> script gets put on a server on which I don't have access
> 2 - why "presumably me" ?
> 
> 
> >
> > > I haven't proven your point, I don't see where I did. On the contrary, I
> > > proved that you can create a simple script that does it. Who asked for
> > any
> > > announcements? who even asked for uploads? The guy used my script to
> > > generate the tarballs from svn on his own machine and then used the
> > > tarballs in his build system and was happy about it. Ideally, the script
> > > should run on a server in a cron job and copy the files to a publically
> > > available directory, I'm not uploading the files because I don't have
> > > access to such server. But that is outside the scope of what was asked, I
> > > helped him get what he wanted, he's happy about it, he'll continue
> > porting
> > > to BSD or whatever he wants to do with it. In the end, we didn't lose a
> > > contributor, and that's the final goal that was reached (who btw said
> > that
> > > he got demotivated after talking to you because of the way you spoke).
> > > Of course, it's less useful than a make distcheck, that's why an actual
> > > build system would be needed for continuous integration checks, but that
> > is
> > > besides the point. They wanted a tarball, I provided a tarball, nothing
> > > more, nothing less.
> > > Stop assuming what the other person wants, and then make judgment calls
> > on
> > > what you think they may or may not want. That's not how you can build
> > your
> > > community, by closing all doors in the face of everyone who wants to
> > help.
> >
> > dude... did you READ AT ALL WHAT VTORRI ASKED FOR? my god! you really want
> > to
> > just run around with your opinions without ever reading the facts. they
> > asked
> > to HAVE daily snapshots. they aren't asking how THEY can do it themselves.
> > they
> > are asking for them to BE done for them. you OFFERED an alternative.
> >
> > man - YOU demotivate ME. your snide comments, grandstanding on your soapbox
> > without ever bothering to READ the discussion or facts at hand - which you
> > very
> > clearly didn't bother to read, or your understanding of english is not so
> > great. when someone asks to have snapshots - they ask for tarballs, which
> > need
> > to be generated and uploaded. we can generate them on the server, but a
> > cron
> > job is no better than a random svn checkout done by them. if you READ the
> > emails and READ the irc discussion you might have the facts.
> >
> > on email i asked what's so hard about svn. on irc i got the response that
> > they
> > have no idea when to svn checkout because they don't know if it works or
> > not.
> > put that together with a cron job either done by them OR us is the same
> > thing.
> > nothing has improved.
> >
> > pointless email as you're simply not reading the actual content.
> >
> you don't seem to read what I wrote, you ignore the facts.. the facts are
> not the commits or how bad they were, the facts were your attitude and
> condescending bullshit. but yeah,you don't seem to be able to acknowledge
> that, since you're perfect and everyone else is wrong.
> 
> Thank you Vincent and Gustavo for sharing your concerns about this, and
> it's too sad that the new contributor has become another victim of raster's
> poor social skills. That's what I wanted to avoid, that's what I wanted
> raster to understand, and I was hoping for him to reply with something like
> "sorry if I offended you, that wasn't my purpose" and that's it, the guy
> stays with us, but I guess raster has too much pride and is too
> self-centered to recognize his own faults.
> I think I will follow Vincent's advice and not reply to t

Re: [E-devel] Fwd: About release, snapshots and openBSD port

[The Rasterman]

On Sun, 13 Nov 2011 02:26:00 +0100 Stefan Schmidt 
said:

> Hello.
> 
> I have not joined any of these flame wares before as I don't think to
> change anything significant but only start to hurt peoples feelings
> for each other. But I had to join here as it started to look like a
> witch hunt on raster here. Please take a moment when reading this.
> Thanks for your time.
> 
> On Sat, 2011-11-12 at 13:43, Youness Alaoui wrote:
> >
> > you don't seem to read what I wrote, you ignore the facts.. the facts are
> > not the commits or how bad they were, the facts were your attitude and
> > condescending bullshit. but yeah,you don't seem to be able to acknowledge
> > that, since you're perfect and everyone else is wrong.
> 
> Great, personal insults are getting us really forward here. This is
> one of the social skills you are calling here for. Discussing with
> others without getting into personal insults. Given this mail and the
> long rant where you "behaved like a dick" (citation from you) are
> letting me wonder if you are able to call others for things you do not
> handle very well on your own. Something to thing about.
> 
> > Thank you Vincent and Gustavo for sharing your concerns about this, and
> > it's too sad that the new contributor has become another victim of raster's
> > poor social skills. That's what I wanted to avoid, that's what I wanted
> > raster to understand, and I was hoping for him to reply with something like
> > "sorry if I offended you, that wasn't my purpose" and that's it, the guy
> > stays with us, but I guess raster has too much pride and is too
> > self-centered to recognize his own faults.
> 
> And you wanted that to happen by forcing him into a corner?
> 
> That is almost always the best recipe to get the opposite of what you
> wanted. Forcing people trigger over reactions from them. Self
> protection, naturally for humans. Changing the behaviour of people is
> a long and exhausting  process. Nothing you can do by sending of
> several mails. And before people even accept what they here from
> others they need to respect them. Respect them for their doings and
> ideas they have come up with over time. Again nothing you can achieve
> in some weeks.
> 
> > I think I will follow Vincent's advice and not reply to this thread
> > anymore, raster clearly showed he has no comprehension of what people are
> > trying to tell him here, so this is just an endless drama with no possible
> > resolution.
> 
> Black and white thinking all around. Sadly we live in a grey world.
> Nothing is only black or only white. Lets have a look at what problems
> we have here and what possible solutions we can come up with. (That
> what we should aim for in the end, a solution bringing the project
> forward).
> 
> Raster is stressed out. Short on time and running at the edge of what
> is possible for him all the time. Thats a fact and on of the biggest
> problems here. Stress calls out on people making hard decisions and
> one of this is being brusque to others. I have observed this a lot at
> myself when being in stressful times. Family and friends had the
> pleasure to get me in such a mood. And even after I recognized this
> at myself (the first step, you know), it is very hard to change at
> all. Again, behaviour changes are the hardest.
> 
> The work part of raster stress we can't influence much. He has to
> handle this on its own. And I personally hope that he realizes how
> near he comes a actual burnout if he keeps going like this for more
> months.
> 
> But now to the things we can change. You and Gustavo are trying to
> change this project in a direction that should be more welcoming for
> developers and users. Making the community grow. I welcome this move,
> but doing something like this can not happen by bringing everything
> down that happened so far. Raster brought this all to the point what
> we have today. Motivating people on the road and de-motivating people
> on the road. Again, very natural as we don't live in flower-power
> land. :)
> 
> So to change to bring in change to this community you need to earn the
> respect of the other developers here before steering the way forward.
> Bluntly speaking nobody wants to accept orders from people he does not
> respect or being paid by. And even the last part may be very hard
> sometimes. ;)
> 
> For the matters at hand the following could be done:
> 
> o Tarballs: Everyone seem to speak about daily tarballs. What I read
>   from the openbsd guys have not been daily tarballs but tarballs for
>   an alpha or rc to check if everything is fine beofre the actual
>   release. Such tarballs are fine and have already been acknowledged
>   and done before. They will even get some QA. And QA is something
>   that differs from daily tarballs, like your script or a simple make
>   disctheck, will produce. SOLUTION: Wait for the alpha and rc
>   tarballs.

yup. exactly my point. :)

> o OpenBSD patches: Vincent asked raster to have a look at the patches.
>

Re: [E-devel] E SVN: barbieri IN trunk/THEMES/detourious: bits images

[The Rasterman]

On Sun, 13 Nov 2011 02:33:22 -0200 Gustavo Sverzut Barbieri
 said:

> On Sun, Nov 13, 2011 at 12:41 AM, hannes.janet...@gmail.com
>  wrote:
> > On Sun, Nov 13, 2011 at 3:40 AM, hannes.janet...@gmail.com
> >  wrote:
> >> On Sat, Nov 12, 2011 at 7:17 PM, Enlightenment SVN
> >>  wrote:
> >>> Log:
> >>> THEMES/detorious: subtle fade of menu separator endings.
> >>>
> >>>  This is less boring than the old one that looked like Windows95 :-)
> >>>
> >> not really liking this one. the full width menu separator is a really
> >> distinguishing feature to me. was hard to get this working in gtk-2.0
> >> and impossible in gtk-3.0 so far.
> >>
> >> http://www.khohar.com/it/hardware/image027.jpg see the difference?
> >>
> > yours is more like win95 :P
> 
> What you mean? it starts fading around 20px on each side, while win95
> is a hard end.  I still think that separators should even be lighter
> in color, with more vertical space. Will look nice, I can try it after
> I'm done with connman (finishing it right now)

speaking of themes... detorious is quite nice - i'd consider it for a default.
it'd need more things in it that cover what it misses (from default). are you
thinking it's worth fixing up and moving to (just require that it is fixed up
to handle all things as default has a requirement to do that).

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


--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/THEMES/detourious: bits images

[Gustavo Sverzut Barbieri]

On Sun, Nov 13, 2011 at 2:54 AM, Carsten Haitzler  wrote:
> On Sun, 13 Nov 2011 02:33:22 -0200 Gustavo Sverzut Barbieri
>  said:
>
>> On Sun, Nov 13, 2011 at 12:41 AM, hannes.janet...@gmail.com
>>  wrote:
>> > On Sun, Nov 13, 2011 at 3:40 AM, hannes.janet...@gmail.com
>> >  wrote:
>> >> On Sat, Nov 12, 2011 at 7:17 PM, Enlightenment SVN
>> >>  wrote:
>> >>> Log:
>> >>> THEMES/detorious: subtle fade of menu separator endings.
>> >>>
>> >>>  This is less boring than the old one that looked like Windows95 :-)
>> >>>
>> >> not really liking this one. the full width menu separator is a really
>> >> distinguishing feature to me. was hard to get this working in gtk-2.0
>> >> and impossible in gtk-3.0 so far.
>> >>
>> >> http://www.khohar.com/it/hardware/image027.jpg see the difference?
>> >>
>> > yours is more like win95 :P
>>
>> What you mean? it starts fading around 20px on each side, while win95
>> is a hard end.  I still think that separators should even be lighter
>> in color, with more vertical space. Will look nice, I can try it after
>> I'm done with connman (finishing it right now)
>
> speaking of themes... detorious is quite nice - i'd consider it for a default.
> it'd need more things in it that cover what it misses (from default). are you
> thinking it's worth fixing up and moving to (just require that it is fixed up
> to handle all things as default has a requirement to do that).

Yes, otherwise it may never catch up. If everyone focus on one theme
it will easily replace default.edc

One thing is that our themes are bit extensive, and it would be good
to have new icons as well. But we are still trying to do every icon
for everything, then lots of work.

Marina, gnome, kde, macos and even windows removed small icons from
menu and most lists. I've discussed this with you already, it's hard
to see the icons (except for you, eagle eyes ;-P), it's hard to do
them. By removing some icons that are basically meaningless we could
help that, leaving few icons to be reworked to provide fresh look (ie:
most configuration icons means nothing, try to figure out what those
key, window et al mean without reading the labels).


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

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] e_fm build and mount problems

[Jochen Schröder]

On 12/11/11 23:03, Vincent Torri wrote:
>
>
> On Sat, 12 Nov 2011, Vincent Torri wrote:
>
>>
>> Hey,
>>
>> On Sat, 12 Nov 2011, Vincent Torri wrote:
>>
>>> Hi all,
>>>
>>> I was trying to dig deeper into a problem where I get a corruption in
>>> e_fm when mounting and removing a usb disk (see
>>> here:http://marc.info/?l=enlightenment-devel&m=132014458110340&w=2 for
>>> details). I found a couple of problems when trying to build e with
>>> different e_fm options.
>>>
>>> 1. when efl is installed in /opt/ for example eeze_mount is always
>>> disabled because the configure test fails because of a missing
>>> -L/opt/e17 in the compile.
>>
>> i don't have libmount, so I can't test it. Can you paste config.log of
>> eeze, please ?
>>
>>>
>>> 2. configure help says enable hal device backend is disabled by default,
>>> however I always have it enabled after configure
>>
>> there is indeed a problem with hal device *backend* (which is actually not
>> disabled by default), but the variable e_cv_want_device_hal is anyway not
>> used at all. So I'm wondering why that part of code is still in
>> configure.ac
>>
>> hal *mount* is enabled by default, and that's what is displayed in the
>> configure output:
>>
>> Preferred Backends:
>>   * device..: eeze
>>   * hal_mount...: enabled
>>   * udisks_mount: enabled
>>   * eeze_mount..:
>>
>> I think i've fixed that in svn. Tell me if there's something wrong.
>>
>>> 3. when I pass --disable-mount-hal to configure the build of
>>> e_fm_main_udisks fails with the following error:
>>>
>>> /usr/bin/ld: e_fm_main_udisks.o: undefined reference to symbol
>>> 'e_dbus_method_call_send'
>>> /usr/bin/ld: note: 'e_dbus_method_call_send' is defined in DSO
>
> try the patch below:
>
> Index: configure.ac
> ===
> --- configure.ac  (revision 65096)
> +++ configure.ac  (working copy)
> @@ -462,6 +462,7 @@
>ecore-ipc>= 1.0.999 \
>eet>= 1.4.0 \
>efreet>= 1.0.999 \
> +edbus>= 1.0.999 \
>eina>= 1.0.999"
>efm_requires+=" $eeze_mount $dbus_mount $hal_mount $udisks_mount"
>
>
> Vincent
>


This fixes the above compilation error.

Cheers
Jochen

> --
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/THEMES/detourious: bits images

[The Rasterman]

On Sun, 13 Nov 2011 03:11:42 -0200 Gustavo Sverzut Barbieri
 said:

> On Sun, Nov 13, 2011 at 2:54 AM, Carsten Haitzler 
> wrote:
> > On Sun, 13 Nov 2011 02:33:22 -0200 Gustavo Sverzut Barbieri
> >  said:
> >
> >> On Sun, Nov 13, 2011 at 12:41 AM, hannes.janet...@gmail.com
> >>  wrote:
> >> > On Sun, Nov 13, 2011 at 3:40 AM, hannes.janet...@gmail.com
> >> >  wrote:
> >> >> On Sat, Nov 12, 2011 at 7:17 PM, Enlightenment SVN
> >> >>  wrote:
> >> >>> Log:
> >> >>> THEMES/detorious: subtle fade of menu separator endings.
> >> >>>
> >> >>>  This is less boring than the old one that looked like Windows95 :-)
> >> >>>
> >> >> not really liking this one. the full width menu separator is a really
> >> >> distinguishing feature to me. was hard to get this working in gtk-2.0
> >> >> and impossible in gtk-3.0 so far.
> >> >>
> >> >> http://www.khohar.com/it/hardware/image027.jpg see the difference?
> >> >>
> >> > yours is more like win95 :P
> >>
> >> What you mean? it starts fading around 20px on each side, while win95
> >> is a hard end.  I still think that separators should even be lighter
> >> in color, with more vertical space. Will look nice, I can try it after
> >> I'm done with connman (finishing it right now)
> >
> > speaking of themes... detorious is quite nice - i'd consider it for a
> > default. it'd need more things in it that cover what it misses (from
> > default). are you thinking it's worth fixing up and moving to (just require
> > that it is fixed up to handle all things as default has a requirement to do
> > that).
> 
> Yes, otherwise it may never catch up. If everyone focus on one theme
> it will easily replace default.edc

sure - agreed. e17 theme tho isn't changing much, so if you just merge in the
missing bits by copying edc/images from default - that'd work for now.

> One thing is that our themes are bit extensive, and it would be good
> to have new icons as well. But we are still trying to do every icon
> for everything, then lots of work.
> 
> Marina, gnome, kde, macos and even windows removed small icons from
> menu and most lists. I've discussed this with you already, it's hard
> to see the icons (except for you, eagle eyes ;-P), it's hard to do
> them. By removing some icons that are basically meaningless we could
> help that, leaving few icons to be reworked to provide fresh look (ie:
> most configuration icons means nothing, try to figure out what those
> key, window et al mean without reading the labels).

i do see your point about all the icons adding to work - BUT... here's my take:
it's good to have them. here is an example that MOST people can't identify with
as they have never been there.

i moved to japan. i didn't read, speak or write japanese. as its not using latin
alphabets.. it's actually IMPOSSIBLE to even understand what a menu says - you
can't guess. its unintelligible squiggles and lines. i literally would spend
ages hunting through phone menus trying everything to finally find the setting
to change to english. at one time i was in front of a mac... in japanese.. but
unlike the phones... it HAD ICONS. i quickly hunted down settings and could
change things even without changing language - the icons were absolutely KEY to
that. i know  most people might not agree - they may never have had that
experience before, but i'm REALLY REALLY REALLY keen on having them for exactly
this reason. if everyone spoke the sample language and used the same alphabet
world-wide it'd be a moot point and icons would only be a prettification.

(as a side note. i noticed when i started learning kanji (chinese characters) i
became very fast at reading them - even when zooming past on a train, i knew
what train station it was - i read the kanji because they were basically icons.
they were immediately recognizable much like the icons we use for toilets
world-wide and many other things, so icons speed up use once you become
familiar with them).

now i DO agree that we have many icons that don't convey meaning very well and
we should address that. really bad ones we should remove and/or replace with a
holder icon so we know it needs work. if you see some of the worst ones - just
do that. we can work our way through over time - this doesn't have to all be
done for a release, but it'd be nice.

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


--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/THEMES/detourious: bits images

[Gustavo Sverzut Barbieri]

On Sun, Nov 13, 2011 at 3:59 AM, Carsten Haitzler  wrote:
> On Sun, 13 Nov 2011 03:11:42 -0200 Gustavo Sverzut Barbieri
>  said:
>
>> On Sun, Nov 13, 2011 at 2:54 AM, Carsten Haitzler 
>> wrote:
>> > On Sun, 13 Nov 2011 02:33:22 -0200 Gustavo Sverzut Barbieri
>> >  said:
>> >
>> >> On Sun, Nov 13, 2011 at 12:41 AM, hannes.janet...@gmail.com
>> >>  wrote:
>> >> > On Sun, Nov 13, 2011 at 3:40 AM, hannes.janet...@gmail.com
>> >> >  wrote:
>> >> >> On Sat, Nov 12, 2011 at 7:17 PM, Enlightenment SVN
>> >> >>  wrote:
>> >> >>> Log:
>> >> >>> THEMES/detorious: subtle fade of menu separator endings.
>> >> >>>
>> >> >>>  This is less boring than the old one that looked like Windows95 :-)
>> >> >>>
>> >> >> not really liking this one. the full width menu separator is a really
>> >> >> distinguishing feature to me. was hard to get this working in gtk-2.0
>> >> >> and impossible in gtk-3.0 so far.
>> >> >>
>> >> >> http://www.khohar.com/it/hardware/image027.jpg see the difference?
>> >> >>
>> >> > yours is more like win95 :P
>> >>
>> >> What you mean? it starts fading around 20px on each side, while win95
>> >> is a hard end.  I still think that separators should even be lighter
>> >> in color, with more vertical space. Will look nice, I can try it after
>> >> I'm done with connman (finishing it right now)
>> >
>> > speaking of themes... detorious is quite nice - i'd consider it for a
>> > default. it'd need more things in it that cover what it misses (from
>> > default). are you thinking it's worth fixing up and moving to (just require
>> > that it is fixed up to handle all things as default has a requirement to do
>> > that).
>>
>> Yes, otherwise it may never catch up. If everyone focus on one theme
>> it will easily replace default.edc
>
> sure - agreed. e17 theme tho isn't changing much, so if you just merge in the
> missing bits by copying edc/images from default - that'd work for now.
>
>> One thing is that our themes are bit extensive, and it would be good
>> to have new icons as well. But we are still trying to do every icon
>> for everything, then lots of work.
>>
>> Marina, gnome, kde, macos and even windows removed small icons from
>> menu and most lists. I've discussed this with you already, it's hard
>> to see the icons (except for you, eagle eyes ;-P), it's hard to do
>> them. By removing some icons that are basically meaningless we could
>> help that, leaving few icons to be reworked to provide fresh look (ie:
>> most configuration icons means nothing, try to figure out what those
>> key, window et al mean without reading the labels).
>
> i do see your point about all the icons adding to work - BUT... here's my 
> take:
> it's good to have them. here is an example that MOST people can't identify 
> with
> as they have never been there.
>
> i moved to japan. i didn't read, speak or write japanese. as its not using 
> latin
> alphabets.. it's actually IMPOSSIBLE to even understand what a menu says - you
> can't guess. its unintelligible squiggles and lines. i literally would spend
> ages hunting through phone menus trying everything to finally find the setting
> to change to english. at one time i was in front of a mac... in japanese.. but
> unlike the phones... it HAD ICONS. i quickly hunted down settings and could
> change things even without changing language - the icons were absolutely KEY 
> to
> that. i know  most people might not agree - they may never have had that
> experience before, but i'm REALLY REALLY REALLY keen on having them for 
> exactly
> this reason. if everyone spoke the sample language and used the same alphabet
> world-wide it'd be a moot point and icons would only be a prettification.
>
> (as a side note. i noticed when i started learning kanji (chinese characters) 
> i
> became very fast at reading them - even when zooming past on a train, i knew
> what train station it was - i read the kanji because they were basically 
> icons.
> they were immediately recognizable much like the icons we use for toilets
> world-wide and many other things, so icons speed up use once you become
> familiar with them).
>
> now i DO agree that we have many icons that don't convey meaning very well and
> we should address that. really bad ones we should remove and/or replace with a
> holder icon so we know it needs work. if you see some of the worst ones - just
> do that. we can work our way through over time - this doesn't have to all be
> done for a release, but it'd be nice.

I know this case and your opinion on this matter. Let's say you're
hurting a lot the common case due a  very rare corner case. Usually
when these things happen you ask someone to help ;-)

Anyway, I could direct you to dozen websites explaining why it is bad,
particularly similar icons (you suggest "holder icon"), as they become
noise. But I'm not in the mood to get into another discussion for
nothing. So do as you wish, no fights this time :-)

BTW, I have Marina's icon for CPU & Temp, but I don't use them and I
think they sh

Re: [E-devel] e_fm build and mount problems

[Jochen Schröder]

On 12/11/11 22:43, Vincent Torri wrote:
>
> Hey,
>
> On Sat, 12 Nov 2011, Vincent Torri wrote:
>
>> Hi all,
>>
>> I was trying to dig deeper into a problem where I get a corruption in
>> e_fm when mounting and removing a usb disk (see
>> here:http://marc.info/?l=enlightenment-devel&m=132014458110340&w=2 for
>> details). I found a couple of problems when trying to build e with
>> different e_fm options.
>>
>> 1. when efl is installed in /opt/ for example eeze_mount is always
>> disabled because the configure test fails because of a missing
>> -L/opt/e17 in the compile.
>
> i don't have libmount, so I can't test it. Can you paste config.log of
> eeze, please ?
>

Sorry I didn't make myself clear, this is compiling E, not eeze. Eeze 
compiled fine with libmount support. However when I compile E and do 
configure it fails the check, the relevant lines of E's config.log are below

configure:15678: checking for eeze_disk_function in -leeze
configure:15703: gcc -std=gnu99 -o conftest -g -O2   conftest.c -leeze 
  -lpam >&5
/usr/bin/ld: cannot find -leeze

This is because I have eeze installed in /opt/e17 which is not in the 
library path and therefore the linker fails. Adding -L/opt/e17/lib to 
configure or export LIBRARY_PATH=/opt/e17/lib fixes this and eeze_mount 
is enabled. I have not figured out a way of making AC_CHECK_LIB actually 
use a non-default library path (mind you as I said earlier I don't 
really know anything about autofoo)

Hope this makes it clearer.

Cheers
Jochen


>>
>> 2. configure help says enable hal device backend is disabled by default,
>> however I always have it enabled after configure
>
> there is indeed a problem with hal device *backend* (which is actually not
> disabled by default), but the variable e_cv_want_device_hal is anyway not
> used at all. So I'm wondering why that part of code is still in
> configure.ac
>
> hal *mount* is enabled by default, and that's what is displayed in the
> configure output:
>
> Preferred Backends:
>* device..: eeze
>* hal_mount...: enabled
>* udisks_mount: enabled
>* eeze_mount..:
>
> I think i've fixed that in svn. Tell me if there's something wrong.
>
>> 3. when I pass --disable-mount-hal to configure the build of
>> e_fm_main_udisks fails with the following error:
>>
>> /usr/bin/ld: e_fm_main_udisks.o: undefined reference to symbol
>> 'e_dbus_method_call_send'
>> /usr/bin/ld: note: 'e_dbus_method_call_send' is defined in DSO
>> /opt/e17/lib/libedbus.so.1 so try adding it to the linker command line
>> /opt/e17/lib/libedbus.so.1: could not read symbols: Invalid operation
>
> no problem here. The symbol e_dbus_method_call_send is in my libedbus. I
> don't know what the problem could be. That symbol exists since e_dbus 1.0.
>
> Note that the EFL are not in /opt/ in my case.
>
>> collect2: ld returned 1 exit status
>> make[4]: *** [enlightenment_fm] Error 1
>> make[4]: Leaving directory
>> `/home/jschrod/Downloads/Enlightenment/e17_src/e/src/bin/e_fm'
>> make[3]: *** [all-recursive] Error 1
>> make[3]: Leaving directory
>> `/home/jschrod/Downloads/Enlightenment/e17_src/e/src/bin'
>> make[2]: *** [all-recursive] Error 1
>> make[2]: Leaving directory
>> `/home/jschrod/Downloads/Enlightenment/e17_src/e/src'
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory `/home/jschrod/Downloads/Enlightenment/e17_src/e'
>> make: *** [all] Error 2
>> /usr/bin/ld: e_fm_main_udisks.o: undefined reference to symbol
>> 'e_dbus_method_call_send'
>> /usr/bin/ld: note: 'e_dbus_method_call_send' is defined in DSO
>> /opt/e17/lib/libedbus.so.1 so try adding it to the linker command line
>> /opt/e17/lib/libedbus.so.1: could not read symbols: Invalid operation
>> collect2: ld returned 1 exit status
>> make[4]: *** [enlightenment_fm] Error 1
>> make[4]: Leaving directory
>> `/home/jschrod/Downloads/Enlightenment/e17_src/e/src/bin/e_fm'
>> make[3]: *** [all-recursive] Error 1
>> make[3]: Leaving directory
>> `/home/jschrod/Downloads/Enlightenment/e17_src/e/src/bin'
>> make[2]: *** [all-recursive] Error 1
>> make[2]: Leaving directory
>> `/home/jschrod/Downloads/Enlightenment/e17_src/e/src'
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory `/home/jschrod/Downloads/Enlightenment/e17_src/e'
>> make: *** [all] Error 2
>>
>> 4. building after configure with --disable-mount-hal and
>> --disable-mount-udisks works (after fixing 1 by exporting LIBRARY_PATH).
>> However the icons for usb-disks never show up on the screen although
>> they are detected by eeze (messages about detected devices show up in
>> xsession-errors).
>
> as I do not have eeze_mount, I think that I can't test that. Maybe Mike
> could look at that
>
> Vincent
>
>> Unfortunately I don't know anything about autofoo, otherwise I would
>> have sent some patches for 1,2 and 3. If I can do anything else let me know.
>>
>> Cheers
>> Jochen
>>
>>
>> --
>> RSA(R) Confe

Re: [E-devel] E SVN: raster trunk/eina

[Vincent Torri]

On Sat, 12 Nov 2011, Enlightenment SVN wrote:

> Log:
> NEWS file like ecore - per vtorri's suggestion

If I'm not mistaken, Boris Faure has added the murmush3 hash in commit 
65017. I don't see it in the NEWS File. And certainly because Boris has 
forgotten to update ChangeLog.

Vincent

>
>
>
> Author:   raster
> Date: 2011-11-12 22:08:35 -0800 (Sat, 12 Nov 2011)
> New Revision: 65120
> Trac: http://trac.enlightenment.org/e/changeset/65120
>
> Modified:
>  trunk/eina/NEWS
>
> Modified: trunk/eina/NEWS
> ===
> --- trunk/eina/NEWS   2011-11-13 06:03:53 UTC (rev 65119)
> +++ trunk/eina/NEWS   2011-11-13 06:08:35 UTC (rev 65120)
> @@ -1,29 +1,40 @@
> -1.1 Release Features
> +Eina 1.1.0
>
> -* Fixed compilation problems with some configure options
> -* Fixed stat issue if file size is in bytes and serial number overran 32bits
> -* Fixed uninstall of mempool modules
> -* Fixed static build of buddy mempool
> -* Fixed stringshare multi-init bug
> -* Fixed windows port of eina_sched_prio_drop
> -* Fixed eina_hash_set to handle data being NULL like eina_hash_del
> -* Fixed static linking to eina (iconv can be avoided)
> -* Fixed eina_share_common_del and eina_share_common_ref unlock bug
> -* Improved scalability/speed improvements in Chained Mempool
> -* Added eina_unicode_strndup API
> -* Added EINA_INLIST_FOREACH_SAFE API
> -* Added Eina unicode UTF8 convenience calls API
> -* Added eina_list_move functions to move list nodes from list to list 
> directly
> -* Added simple SAX XML parser API added
> -* Added inlist sort and sorted insert API
> -* Added mempool repack API
> -* Added eina_file API for portable file memory-mapping with IO saffety traps
> -* Added thread locks, conditions etc. wrapper API for portability
> -* Added prefix API for apps or libs to find their runtime prefix location
> -* Added refcount macro API
> -* Added binbuf for binary extendable buffers API
> -* Added eina_hash_free_cb_set API
> -* Added eina_main_loop_is API
> -* Added eina_strbuf_manage_new and eina_ustrbuf_manage_new APIs
> -* Added eina_xattr API's
> -* Changed to stringshare as storage eina error strings now
> +Changes since Eina 1.0.0:
> +--
> +
> +Additions:
> +
> +* eina_unicode_strndup API
> +* EINA_INLIST_FOREACH_SAFE API
> +* eina unicode UTF8 convenience calls API
> +* eina_list_move functions to move list nodes from list to list directly
> +* simple SAX XML parser API added
> +* inlist sort and sorted insert API
> +* mempool repack API
> +* eina_file API for portable file memory-mapping with IO saffety traps
> +* thread locks, conditions etc. wrapper API for portability
> +* prefix API for apps or libs to find their runtime prefix location
> +* refcount macro API
> +* binbuf for binary extendable buffers API
> +* eina_hash_free_cb_set API
> +* eina_main_loop_is API
> +* eina_strbuf_manage_new and eina_ustrbuf_manage_new APIs
> +* eina_xattr API's
> +
> +Fixes:
> +
> +* compilation problems with some configure options
> +* stat issue if file size is in bytes and serial number overran 32bits
> +* uninstall of mempool modules
> +* static build of buddy mempool
> +* stringshare multi-init bug
> +* windows port of eina_sched_prio_drop
> +* eina_hash_set to handle data being NULL like eina_hash_del
> +* static linking to eina (iconv can be avoided)
> +* eina_share_common_del and eina_share_common_ref unlock bug
> +
> +Improvements:
> +
> +* scalability/speed improvements in Chained Mempool
> +* stringshare as storage for eina error strings now
>
>
> --
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
>

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] e_fm build and mount problems

[Vincent Torri]

On Sun, 13 Nov 2011, Jochen Schröder wrote:


On 12/11/11 22:43, Vincent Torri wrote:


Hey,

On Sat, 12 Nov 2011, Vincent Torri wrote:


Hi all,

I was trying to dig deeper into a problem where I get a corruption in
e_fm when mounting and removing a usb disk (see
here:http://marc.info/?l=enlightenment-devel&m=132014458110340&w=2 for
details). I found a couple of problems when trying to build e with
different e_fm options.

1. when efl is installed in /opt/ for example eeze_mount is always
disabled because the configure test fails because of a missing
-L/opt/e17 in the compile.


i don't have libmount, so I can't test it. Can you paste config.log of
eeze, please ?



Sorry I didn't make myself clear, this is compiling E, not eeze. Eeze
compiled fine with libmount support. However when I compile E and do
configure it fails the check, the relevant lines of E's config.log are below

configure:15678: checking for eeze_disk_function in -leeze
configure:15703: gcc -std=gnu99 -o conftest -g -O2   conftest.c -leeze
 -lpam >&5
/usr/bin/ld: cannot find -leeze


that is strange: the eeze.pc file should have -L/opt/e17/lib -leeze in the 
Libs entry.


One possible reason to not have -L***: you have previously installed eeze 
in /usr, removed the files manually except /usr/lib/pkgconfig/eeze.pc. 
Then installed eeze in /opt/e17, without updating PKG_CONFIG_PATH. So it's 
the eeze.pc in /usr/lib/pkgconfig which is used.


So verify first that there is not an eeze.pc file somewhere else

Vincent



This is because I have eeze installed in /opt/e17 which is not in the
library path and therefore the linker fails. Adding -L/opt/e17/lib to
configure or export LIBRARY_PATH=/opt/e17/lib fixes this and eeze_mount
is enabled. I have not figured out a way of making AC_CHECK_LIB actually
use a non-default library path (mind you as I said earlier I don't
really know anything about autofoo)

Hope this makes it clearer.

Cheers
Jochen




2. configure help says enable hal device backend is disabled by default,
however I always have it enabled after configure


there is indeed a problem with hal device *backend* (which is actually not
disabled by default), but the variable e_cv_want_device_hal is anyway not
used at all. So I'm wondering why that part of code is still in
configure.ac

hal *mount* is enabled by default, and that's what is displayed in the
configure output:

Preferred Backends:
   * device..: eeze
   * hal_mount...: enabled
   * udisks_mount: enabled
   * eeze_mount..:

I think i've fixed that in svn. Tell me if there's something wrong.


3. when I pass --disable-mount-hal to configure the build of
e_fm_main_udisks fails with the following error:

/usr/bin/ld: e_fm_main_udisks.o: undefined reference to symbol
'e_dbus_method_call_send'
/usr/bin/ld: note: 'e_dbus_method_call_send' is defined in DSO
/opt/e17/lib/libedbus.so.1 so try adding it to the linker command line
/opt/e17/lib/libedbus.so.1: could not read symbols: Invalid operation


no problem here. The symbol e_dbus_method_call_send is in my libedbus. I
don't know what the problem could be. That symbol exists since e_dbus 1.0.

Note that the EFL are not in /opt/ in my case.


collect2: ld returned 1 exit status
make[4]: *** [enlightenment_fm] Error 1
make[4]: Leaving directory
`/home/jschrod/Downloads/Enlightenment/e17_src/e/src/bin/e_fm'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/home/jschrod/Downloads/Enlightenment/e17_src/e/src/bin'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/home/jschrod/Downloads/Enlightenment/e17_src/e/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/jschrod/Downloads/Enlightenment/e17_src/e'
make: *** [all] Error 2
/usr/bin/ld: e_fm_main_udisks.o: undefined reference to symbol
'e_dbus_method_call_send'
/usr/bin/ld: note: 'e_dbus_method_call_send' is defined in DSO
/opt/e17/lib/libedbus.so.1 so try adding it to the linker command line
/opt/e17/lib/libedbus.so.1: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[4]: *** [enlightenment_fm] Error 1
make[4]: Leaving directory
`/home/jschrod/Downloads/Enlightenment/e17_src/e/src/bin/e_fm'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/home/jschrod/Downloads/Enlightenment/e17_src/e/src/bin'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/home/jschrod/Downloads/Enlightenment/e17_src/e/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/jschrod/Downloads/Enlightenment/e17_src/e'
make: *** [all] Error 2

4. building after configure with --disable-mount-hal and
--disable-mount-udisks works (after fixing 1 by exporting LIBRARY_PATH).
However the icons for usb-disks never show up on the screen although
they are detected by eeze (messages about detected devices show up in
xsession-errors).


as I do not have eeze_mount, I think that I can't test that. Maybe Mike
could look at that

Vincent


Unfortunately I d