[E-devel] [Patch] [Ejde, Elementary] added checking layout to entry selection handler

2012-07-23 Thread Myung-Jae Lee
Dear all,
This is the extension patch for the previous 'selection handler' and 'viewport 
check' in entry.

Selection handlers will be displayed on the top or bottom of the selection 
block according to the position of the layout that is contained in conformant.
Elm_entry queries the layout region from the geometry of the conformant that 
contains the entry itself, and pass the information to edje_entry as the same 
way with the viewport region.

Because this patch is based on the previous patches, apply the next patches 
first and this later.
-  selection handler patch : [E-devel] [Patch] [Ejde, Elementary] added 
selection handler feature to entry
-  viewport check patch : [E-devel] [Patch] [Ejde, Elementary] added viewport 
check to entry selection handler

Please review this patch and feel free to give me feedbacks when you have 
questions.

Regards,
--
Myungjae Lee

edje_entry.layout.diff
Description: Binary data


elm_entry.layout.diff
Description: Binary data


handler_start_top.png
Description: Binary data


handler_start_bottom.png
Description: Binary data


handler_end_top.png
Description: Binary data


handler_end_bottom.png
Description: Binary data
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [patch] Link copying fix

2012-07-23 Thread The Rasterman
On Fri, 20 Jul 2012 22:43:21 +0200 rustyBSD rusty...@gmx.fr said:

 (re)Hi,
 when copying symlinks, it creates a symlink to the
 destination but with the name of the pointed file/folder.
 
 It causes problems, ex: we can't copy two symlinks
 pointing to the same file, because they will have the
 same name.
 
 Here is a patch which corrects this. I also found other
 problems and bugs in file managing; I will look at it
 tomorrow.
 
 ps: I don't have svn commit access.

i don't know about you.. but i'm happily copying a dir with 2 symlinks pointing
to the same file. with efm. slight issue. it seems to make the file pointed to
have the same perms as the symlinks. :) but if only 1 file points to it even.

nb your patch also leaks memory. you don't free lnk_path or dst_dir - both of
which are alloced. you recompose dst_path when task-desk.name is sufficient
to use. also using ecore_readlink instead of readlink - fine, but i'm failing
to see the bug you're fixing :(  it does the exact same work, just using ecore
calls...

hmm looking at svn someone has committed half your patch with leaks fixed, but
i'm failing to see the bug fix ? :)

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


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] Race condition

2012-07-23 Thread rustyBSD
Hi,
I was told that I have to explain race conditions I found.

I. Copy file bytes
It concerns 'e_fm_op.c.diff1'. When copying a file, the dest
file is written with bytes read from source file. It only stops
when we are at the end of the source file. The problem
is that you just have to launch a program like this:

#include stdio.h
#include stdlib.h
#include string.h

int main()
{
   char buf[] = a;

   FILE* f = fopen(file.txt, wb);
   if (f)
 {
   while(1)
 fwrite(buf, sizeof(buf), 1, f);
 }
   fclose(f);
}

And then right-click-copy 'file.txt' to another place to cause
e to indefinitly copy the file (as it never arrives to the end
of the file).

This point is not discutable. When you copy a file, you ONLY
must copy n bytes (got by xx.st_size) of source file. It's like
in file transfer. You get size of file, you split it in blocks and
send them, and you recalculate the size of the last block to
have sent exactly the bytes of file. Otherwise, you can flood
the server.

Quick ex:
   block size - 100 b
   got file size - 246 b
   So:
copy 100 b
copy 100 b
copy 46 b

That's it. The file is copied at its original size, even if it has
changed since the copy has been started.


II. Copy file (2 race conditions)
When copying a simple file, we do:
1. check type of file with stat().
2. if dest file doesn't exist
--  2.1 if file is a regular file, then copy.
--  2.2 ...
3. else: ask for overwrite

There is a TOCTOU.

Betwenn 2 and 3, you just have to replace the file by a symlink
to make the copy copy the file pointed by the link.

Between 1 and 2, you just have to create a symlink to the destination,
to make the copy copy the source file in the file pointed by the symlink.

You can test:
- add 'sleep(10);' to the line 1231 of 'e_fm_op.c'
- copy a file to an empty folder
- create quickly a symlink in the dest folder with the same name of the
  file which will be copied, pointing to another file
- wait... and then, check the file pointed by the symlink: its content has
  been overwritten by the source file of the copy

Now, keep the sleep(), apply all patches joined to this mail, and retry.
You will see that e doesn't copy file, because it detects that file type
has been changed.



I was also told that my patches are causing problems and that there are
no race condition (although if you test, you will see that there are),
so I'm
waiting for the response of raster to know what problem(s) it causes.

Maxime.
--- e_fm/e_fm_ipc.c	2012-07-22 16:47:04.0 +0200
+++ e_fm/e_fm_ipc.c	2012-07-22 17:05:43.138103151 +0200
@@ -1087,7 +1087,7 @@
 //   printf(MOD %s %3.3f\n, path, ecore_time_unix_get());
lnk = ecore_file_readlink(path);
memset(st, 0, sizeof(struct stat));
-   if (stat(path, st) == -1)
+   if (lstat(path, st) == -1)
  {
 if ((path[0] == 0) || (lnk)) broken_lnk = 1;
 else return;
--- e_fm_op.c	2012-07-22 17:02:46.0 +0200
+++ e_fm_op.c	2012-07-22 17:14:15.19933 +0200
@@ -33,6 +33,8 @@
 #include errno.h
 #include limits.h
 
+#include fcntl.h
+
 #include Ecore.h
 #include Ecore_File.h
 
@@ -81,6 +83,7 @@
 static int   _e_fm_op_copy_link(E_Fm_Op_Task *task);
 static int   _e_fm_op_copy_fifo(E_Fm_Op_Task *task);
 static int   _e_fm_op_open_files(E_Fm_Op_Task *task);
+static int   _e_fm_op_check_race(E_Fm_Op_Task *task);
 static int   _e_fm_op_copy_chunk(E_Fm_Op_Task *task);
 
 static int   _e_fm_op_copy_atom(E_Fm_Op_Task *task);
@@ -118,6 +121,7 @@
{
   const char *name;
   struct stat st;
+  struct stat st_fs;
} src;
 
struct
@@ -1228,6 +1232,8 @@
 _e_fm_op_open_files(E_Fm_Op_Task *task)
 {
E_Fm_Op_Copy_Data *data = task-data;
+   int fd_from;
+   int fd_to;
 
/* Ordinary file. */
if (!data)
@@ -1240,14 +1246,43 @@
 
if (!data-from)
  {
-data-from = fopen(task-src.name, rb);
+fd_from = open(task-src.name, O_RDONLY);
+if(fd_from == -1)
+  {
+_E_FM_OP_ERROR_SEND_WORK(task, E_FM_OP_ERROR, Cannot open file '%s' for reading: %s., task-src.name);
+  }
+
+data-from = fdopen(fd_from, rb);
 if (!data-from)
   _E_FM_OP_ERROR_SEND_WORK(task, E_FM_OP_ERROR, Cannot open file '%s' for reading: %s., task-src.name);
+
+if (fstat(fd_from, task-src.st_fs) == -1)
+  {
+_E_FM_OP_ERROR_SEND_WORK(task, E_FM_OP_ERROR, Cannot fstat() file '%s'., task-src.name);
+  }
+
+if (_e_fm_op_check_race(task))
+  {
+fclose(data-from);
+data-from = NULL;
+
+FREE(task-data);
+
+task-finished = 1;
+
+return 1;
+  }
  }
 
if (!data-to)
  {
-data-to = fopen(task-dst.name, wb);
+fd_to = open(task-dst.name, O_WRONLY | O_CREAT | O_EXCL);
+if(fd_to == -1)
+  {
+_E_FM_OP_ERROR_SEND_WORK(task, E_FM_OP_ERROR, Cannot open file '%s' for 

Re: [E-devel] [patch] Link copying fix

2012-07-23 Thread rustyBSD
Strange thing you are telling me.

$ svn update -r 74262  # just before my patch was committed
...
$ ln -s /home link1
$ ln -s /home link2
right-click on link1 - copy to an empty folder
right-click on link2 - copy to the same folder

Annnd... File already exists.

Of course, if you test with the actual svn revision, you can't
see this problem. (And it's not a bug, just a misconception.)



Le 23/07/2012 09:57, Carsten Haitzler (The Rasterman) a écrit :
 On Fri, 20 Jul 2012 22:43:21 +0200 rustyBSD rusty...@gmx.fr said:

 (re)Hi,
 when copying symlinks, it creates a symlink to the
 destination but with the name of the pointed file/folder.

 It causes problems, ex: we can't copy two symlinks
 pointing to the same file, because they will have the
 same name.

 Here is a patch which corrects this. I also found other
 problems and bugs in file managing; I will look at it
 tomorrow.

 ps: I don't have svn commit access.
 i don't know about you.. but i'm happily copying a dir with 2 symlinks 
 pointing
 to the same file. with efm. slight issue. it seems to make the file pointed to
 have the same perms as the symlinks. :) but if only 1 file points to it even.

 nb your patch also leaks memory. you don't free lnk_path or dst_dir - both of
 which are alloced. you recompose dst_path when task-desk.name is sufficient
 to use. also using ecore_readlink instead of readlink - fine, but i'm failing
 to see the bug you're fixing :(  it does the exact same work, just using ecore
 calls...

 hmm looking at svn someone has committed half your patch with leaks fixed, but
 i'm failing to see the bug fix ? :)



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] bugs to clear up before release

2012-07-23 Thread The Rasterman
On Fri, 20 Jul 2012 14:02:46 -0300 Leandro Pereira lean...@profusion.mobi
said:

 On 07/20/2012 06:29 AM, Carsten Haitzler (The Rasterman) wrote:
  i have just gone through elementary test and elm has a LOAD of bugs - almost
  all of them new since last release. here is my current efl buglist in
  short: can people when they get time look at these and work on fixing
  them? :)
 
  bugs:
 
 elm - popup with items crashes

oooh i just blew my. stack! :)

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


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: kakaroto trunk/GAMES/eskiss/data/edje

2012-07-23 Thread Youness Alaoui
Ah ok, thanks for the clarification. Issue was that edje_cc complains now
with an error, so eskiss wasn't compiling anymore.

On Sat, Jul 21, 2012 at 4:28 PM, Gustavo Sverzut Barbieri 
barbi...@profusion.mobi wrote:

 On Sat, Jul 21, 2012 at 1:50 PM, Enlightenment SVN
 no-re...@enlightenment.org wrote:
  Log:
  Eskiss: default part type is not RECT anymore so we need to explicitely
 specify it

 actually it was never rect, but image. But images were handled exactly
 like rects in the clipper case. We expect to have special case to clip
 to images some day, so the warning right now.


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


 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] [PATCH] evas/wayland_egl: Fix segfault when doing alpha setting in elmentary.

2012-07-23 Thread zhiwen . wu
From: Alex Wu zhiwen...@linux.intel.com

When calling elm_win_alpha_set(), the global EGLContext object keep
unchanged, but the new EGLSurface object subjects to the new EGLConfig
with changed alpha_size. This makes eng_window_new() failed and hence
free the  Render_Engine object (e-engine.data.output) and nullize it.
Next time other objects reference the output, segfault occurs.

In this patch, I give every Evas_GL_Wl_Window object a EGLContext object
and all these EGLContext objects share the same shader program objects.

A new global EGLContext object share_context added, which is
responsible for keeping the shared objects alive. e.g. shader program
objects.At the first time succeeded to create a EGLContext, assign it to
the share_context, and should not destory it in eng_window_free.

The share_context will be taken as the 3rd argument when calling
eglCreateContext(), and then updated to the new created EGLContext to
keep the shared gl objects available.

Thanks for devilhorns' review and suggestion.
---
 .../src/modules/engines/wayland_egl/evas_engine.c  |   41 
 .../src/modules/engines/wayland_egl/evas_wl_main.c |   21 +-
 2 files changed, 37 insertions(+), 25 deletions(-)

diff --git a/trunk/evas/src/modules/engines/wayland_egl/evas_engine.c 
b/trunk/evas/src/modules/engines/wayland_egl/evas_engine.c
index 7dc158b..758481b 100644
--- a/trunk/evas/src/modules/engines/wayland_egl/evas_engine.c
+++ b/trunk/evas/src/modules/engines/wayland_egl/evas_engine.c
@@ -600,6 +600,7 @@ eng_setup(Evas *e, void *in)
 {
Render_Engine *re;
Evas_Engine_Info_Wayland_Egl *info;
+   Evas_GL_Wl_Window *new_win = NULL;
 
info = (Evas_Engine_Info_Wayland_Egl *)in;
if (!e-engine.data.output)
@@ -679,28 +680,36 @@ eng_setup(Evas *e, void *in)
return 0;
 }
 
-  if (re-win)
-{
-   re-win-gl_context-references++;
-   eng_window_free(re-win);
-   inc = 1;
-   gl_wins--;
-}
-  re-w = e-output.w;
-  re-h = e-output.h;
-  re-win = eng_window_new(re-info-info.display,
+  new_win = eng_window_new(re-info-info.display,
re-info-info.surface,
re-info-info.screen,
re-info-info.depth,
-   re-w, re-h,
+   e-output.w, e-output.h,
re-info-indirect,
re-info-info.destination_alpha,
re-info-info.rotation);
-  eng_window_use(re-win);
-  if (re-win) gl_wins++;
-  if ((re-win)  (inc))
- re-win-gl_context-references--;
-   }
+
+  if (new_win) 
+{
+   // free old win
+   if (re-win)
+ {
+re-win-gl_context-references++;
+eng_window_free(re-win);
+inc = 1;
+gl_wins--;
+ }
+
+   re-win = new_win;
+   re-w = e-output.w;
+   re-h = e-output.h;
+
+   eng_window_use(re-win);
+   if (re-win) gl_wins++;
+   if ((re-win)  (inc))
+   re-win-gl_context-references--;
+}
+}
  else if ((re-win-w != e-output.w) ||
   (re-win-h != e-output.h))
{
diff --git a/trunk/evas/src/modules/engines/wayland_egl/evas_wl_main.c 
b/trunk/evas/src/modules/engines/wayland_egl/evas_wl_main.c
index 58ab1c3..c5f9721 100644
--- a/trunk/evas/src/modules/engines/wayland_egl/evas_wl_main.c
+++ b/trunk/evas/src/modules/engines/wayland_egl/evas_wl_main.c
@@ -2,7 +2,7 @@
 
 static Evas_GL_Wl_Window *_evas_gl_wl_window = NULL;
 
-static EGLContext context = EGL_NO_CONTEXT;
+static EGLContext share_context = EGL_NO_CONTEXT;
 
 // fixme: something is up/wrong here - dont know what tho...
 //#define NEWGL 1
@@ -146,21 +146,22 @@ eng_window_new(struct wl_display *disp, struct wl_surface 
*surface, int screen,
  {
 ERR(eglCreateWindowSurface() fail for %p. code=%#x,
 gw-win, eglGetError());
-   eng_window_free(gw);
+eng_window_free(gw);
 return NULL;
  }
 
-   if (context == EGL_NO_CONTEXT)
- context = eglCreateContext(gw-egl_disp, gw-egl_config, NULL,
-context_attrs);
-   gw-egl_context[0] = 

Re: [E-devel] bugs to clear up before release

2012-07-23 Thread ChunEon Park
yes.. certainly, scroller.


Pending to tomorrow.




-Regards, Hermet-

-Original Message-
From: Cedric BAILlt;cedric.b...@free.frgt; 
To: Carsten Haitzlerlt;ras...@rasterman.comgt;; 
Cc: Enlightenment developer 
listlt;enlightenment-devel@lists.sourceforge.netgt;; 
Sent: 2012-07-23 (월) 14:45:07
Subject: Re: [E-devel] bugs to clear up before release

On Mon, Jul 23, 2012 at 1:13 PM, Carsten Haitzler 
lt;rastergt;@rasterman.comgt; wrote:
gt; On Mon, 23 Jul 2012 12:25:51 +0900 Cedric BAIL 
lt;cedric.bailgt;@free.frgt; said:
gt;gt; On Fri, Jul 20, 2012 at 6:46 PM, Cedric BAIL 
lt;cedric.bailgt;@free.frgt; wrote:
gt;gt; gt; On Fri, Jul 20, 2012 at 6:29 PM, Carsten Haitzler 
lt;rastergt;@rasterman.comgt;
gt;gt; gt; wrote:
gt;gt; gt;gt; i have just gone through elementary test and elm has a LOAD 
of bugs -
gt;gt; gt;gt; almost all of them new since last release. here is my current 
efl buglist
gt;gt; gt;gt; in short: can people when they get time look at these and 
work on fixing
gt;gt; gt;gt; them? :)
gt;gt; gt;
gt;gt; gt; Sadly a lot of work before we can do a release. Let's focus on 
that.
gt;gt; gt;
gt;gt; gt;gt; bugs:
gt;gt; gt;gt; elm - photocam when zooming scrolll jumps about
gt;gt; gt;gt; edje - edje entry doesnt EXPAND selection to positon when 
holding shift
gt;gt; gt;gt; down elm - flip interactive - broken at detecting end of flip 
(moude up?)
gt;gt; gt;gt; elm - entry 7 - ctx menu ant be added in desktop mode (right 
click)
gt;gt; gt;gt; elm - entry 7 - item cant be selected unless text follows it
gt;gt; gt;gt; elm - entry anchor - anchor click does nothing
gt;gt; gt;gt; elm - entry scrolled - if mouse over scrollbar, normal cursor 
should be
gt;gt; gt;gt; shown elm - video - player controls are screwed (edje 
complaining of
gt;gt; gt;gt; fixed: 1 1) emotion - generic (vlc) module doesnt seem to be 
able to loop
gt;gt; gt;gt; in terminology elm - genlist 2 - resize down to be scrollable 
and sb
gt;gt; gt;gt; show/hide - size wrong elm - genlist decorate all mode on and 
scroll -
gt;gt; gt;gt; garbage items left around elm - ctxpopup - looks pretty crap 
on desktop
gt;gt; gt;gt; profile - spacing bad etc. elm - tooltip - big icon tooltip 
doesnt show
gt;gt; gt;gt; elm - tooltip - insanely big icon tooltip doesnt show
gt;gt; gt;gt; elm - slider - vertical sllider units dont change min width 
when txt
gt;gt; gt;gt; changes elm - spinner - really broken - text gets selected on 
button
gt;gt; gt;gt; up/down press elm - spinner - months dont change on button 
press
gt;gt; gt;gt; elm - colorselector - instasegv
gt;gt; gt;
gt;gt; gt; This one is fixed in svn since this morning normally.
gt;gt; gt;
gt;gt; gt;gt; elm - index - ??? (not bug - note in desktop mode its not 
very useful)
gt;gt; gt;gt; elm - calendar - slow to show window (same with calendar 2 
etc.)
gt;gt; gt;
gt;gt; gt; I was after that one, and it does make edje_calc crazy. Need more
gt;gt; gt; investigation.
gt;gt; gt;
gt;gt; gt;gt; elm - toolbar - doesnt go into menu mode until alrready 
losing icons
gt;gt; gt;gt; elm - toolbar 2 - arrows at end when pressed dont select 
up/down 1 item
gt;gt; gt;gt; elm - menu - arrow for submenu in menu item over text label 
not next to it
gt;gt; gt;gt; elm - toolbar 8 - clip for open/close submenu wrong at top
gt;gt; gt;gt; elm - window inline - fovcus doesnt work in inline entry
gt;gt; gt;
gt;gt; gt; elm - focus is also broken with scroller.
gt;gt;
gt;gt; elm panes is also broekn, noticed in clouseau :-(
gt;
gt; in what way? at leats elm test panes seems fine.

In clouseau, the arrow may stay arround. Very easy to reproduce. Maybe
related to the change to the scroller as both left and right object
have one with clouseau.
-- 
Cedric BAIL

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [PATCH] evas/wayland_egl: Fix segfault when doing alpha setting in elmentary.

2012-07-23 Thread Chris Michael
Applied to svn (74330). Many thanks :)

Dh


 -Original Message-
 From: zhiwen...@linux.intel.com [mailto:zhiwen...@linux.intel.com]
 Sent: 23 July 2012 14:10
 To: enlightenment-devel@lists.sourceforge.net
 Cc: eduardo.de.barros.l...@intel.com
 Subject: [E-devel] [PATCH] evas/wayland_egl: Fix segfault when doing
 alpha setting in elmentary.
 
 From: Alex Wu zhiwen...@linux.intel.com
 
 When calling elm_win_alpha_set(), the global EGLContext object keep
 unchanged, but the new EGLSurface object subjects to the new EGLConfig
 with changed alpha_size. This makes eng_window_new() failed and hence
 free the  Render_Engine object (e-engine.data.output) and nullize it.
 Next time other objects reference the output, segfault occurs.
 
 In this patch, I give every Evas_GL_Wl_Window object a EGLContext
 object
 and all these EGLContext objects share the same shader program objects.
 
 A new global EGLContext object share_context added, which is
 responsible for keeping the shared objects alive. e.g. shader program
 objects.At the first time succeeded to create a EGLContext, assign it
 to
 the share_context, and should not destory it in eng_window_free.
 
 The share_context will be taken as the 3rd argument when calling
 eglCreateContext(), and then updated to the new created EGLContext to
 keep the shared gl objects available.
 
 Thanks for devilhorns' review and suggestion.
 ---
  .../src/modules/engines/wayland_egl/evas_engine.c  |   41
 
  .../src/modules/engines/wayland_egl/evas_wl_main.c |   21 +-
  2 files changed, 37 insertions(+), 25 deletions(-)
 
 diff --git a/trunk/evas/src/modules/engines/wayland_egl/evas_engine.c
 b/trunk/evas/src/modules/engines/wayland_egl/evas_engine.c
 index 7dc158b..758481b 100644
 --- a/trunk/evas/src/modules/engines/wayland_egl/evas_engine.c
 +++ b/trunk/evas/src/modules/engines/wayland_egl/evas_engine.c
 @@ -600,6 +600,7 @@ eng_setup(Evas *e, void *in)
  {
 Render_Engine *re;
 Evas_Engine_Info_Wayland_Egl *info;
 +   Evas_GL_Wl_Window *new_win = NULL;
 
 info = (Evas_Engine_Info_Wayland_Egl *)in;
 if (!e-engine.data.output)
 @@ -679,28 +680,36 @@ eng_setup(Evas *e, void *in)
 return 0;
  }
 
 -  if (re-win)
 -{
 -   re-win-gl_context-references++;
 -   eng_window_free(re-win);
 -   inc = 1;
 -   gl_wins--;
 -}
 -  re-w = e-output.w;
 -  re-h = e-output.h;
 -  re-win = eng_window_new(re-info-info.display,
 +  new_win = eng_window_new(re-info-info.display,
 re-info-info.surface,
 re-info-info.screen,
 re-info-info.depth,
 -   re-w, re-h,
 +   e-output.w, e-output.h,
 re-info-indirect,
 re-info-
 info.destination_alpha,
 re-info-info.rotation);
 -  eng_window_use(re-win);
 -  if (re-win) gl_wins++;
 -  if ((re-win)  (inc))
 - re-win-gl_context-references--;
 -   }
 +
 +  if (new_win)
 +{
 +   // free old win
 +   if (re-win)
 + {
 +re-win-gl_context-references++;
 +eng_window_free(re-win);
 +inc = 1;
 +gl_wins--;
 + }
 +
 + re-win = new_win;
 + re-w = e-output.w;
 + re-h = e-output.h;
 +
 + eng_window_use(re-win);
 + if (re-win) gl_wins++;
 + if ((re-win)  (inc))
 + re-win-gl_context-references--;
 +}
 +  }
   else if ((re-win-w != e-output.w) ||
(re-win-h != e-output.h))
 {
 diff --git a/trunk/evas/src/modules/engines/wayland_egl/evas_wl_main.c
 b/trunk/evas/src/modules/engines/wayland_egl/evas_wl_main.c
 index 58ab1c3..c5f9721 100644
 --- a/trunk/evas/src/modules/engines/wayland_egl/evas_wl_main.c
 +++ b/trunk/evas/src/modules/engines/wayland_egl/evas_wl_main.c
 @@ -2,7 +2,7 @@
 
  static Evas_GL_Wl_Window *_evas_gl_wl_window = NULL;
 
 -static EGLContext context = EGL_NO_CONTEXT;
 +static EGLContext share_context = EGL_NO_CONTEXT;
 
  // fixme: something is up/wrong here - dont know what tho...
  //#define NEWGL 1
 @@ 

[E-devel] [PATCH]Evas.h comments patch

2012-07-23 Thread Ingvaldur Sigurjonsson
When reading the comments of 'evas_object_textgrid_update_add' I noticed 
a little cnp err. The enclosed patch is just a suggestion, but the 
misleading comment was driving me nuts...


Regards
- Ingvaldur
Index: src/lib/Evas.h
===
--- src/lib/Evas.h	(revision 74295)
+++ src/lib/Evas.h	(working copy)
@@ -9462,15 +9462,15 @@
 EAPI Evas_Textgrid_Cell *evas_object_textgrid_cellrow_get(const Evas_Object *obj, int y);
 
 /**
- * @brief Get the string at the given row of the given textgrid object.
+ * @brief Indicate for evas that part of a textgrid region (cells) has been updated.
  *
- * @param obj The textgrid object to query for font information.
+ * @param obj The textgrid object.
  * @param x The rect region of cells top-left x (column)
  * @param y The rect region of cells top-left y (row)
  * @param w The rect region size in number of cells (columns)
  * @param h The rect region size in number of cells (rows)
  *
- * This function delcares to evas that a region of cells was updated by
+ * This function declares to evas that a region of cells was updated by
  * code and needs refreshing. An application should modify cells like this
  * as an example:
  * 
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [Enlightenment-intl] problem with contributions from batden

2012-07-23 Thread The Rasterman
On Wed, 11 Jul 2012 21:30:50 +0200 Chidambar 'ilLogict' Zinnoury
illog...@online.fr said:

actually i'm getting a bit bored of no response, so... let's let things drop as
they stand right now without a response.

here is what i say. you (illogict) have commit access. that gives you the
ability to commit what you feel needs doing. of course like anything in a
group/team, trampling on someone elses work is frowned upon if its bad. ie
creates trouble. any sane person would LOVE the fact that someone - ANYONE came
along and fixed their bugs for them. bad spelling/grammar in translations are
bugs. i'm never going to complain about that because its a nice contribution
saving me time. i'll smile and say thanks mate!. 

imho not being able to see the positive in something like that is like
trampling over some part of svn where you don't belong and creating trouble for
the person working there. it's just the reverse - it's stifling work.

as for official translators - people in charge of translations. we NEVER
officially assigned anything. stuff around here is done fairly loosely. the
more the item (code vs theme vs translation etc.) the more careful you need to
be as the repercussions of conflicts and issues are larger, but translations
have fairly minimal side-effects, so it's more free.

so since batden doesn't want to respond - here's my take. put your fixed
version back if you believe it is better than what is there now (and i do
believe you think that). my french isn't sufficient to decide which is better
for you :) just fix it back to where you are happy and finish off with a
ah.. le tabernac!. if batden wants to input on this he can do so at a
later date, as can anyone else. :)

  Hi all.
 
  I'm reluctantly writing today to discuss a problem currently happening
 with Philippe Guillaumie (batden) and the French translation. I'm not
 sending this light-hearted, but because my attempts to communicate with
 him failed: I'm still waiting for a reply to my e-mail, and he's
 nowhere to be seen on IRC.
 
  A little bit over a month ago, a colleague of mine came to me to tell
 me about the poor state of the French translation in Enlightenment:
 some strings were undecipherable, whereas some were completely
 misleading and made him do wrong actions (especially Reboot and
 Restart Enlightenment). I then had a quick look a the file, which
 made me awe in shock by seeing the orthography and grammar mistakes,
 and moreover the poorly worded and syntaxed sentences (even on strings
 I happened to translate years ago!) They were certainly not up to the
 quality that could be expected. I thus made a quick fix for some
 strings (especially Reboot and friends), and changed at the same time
 the team's address back to enlightenment-intl from his own, as I felt
 it should be: a single individual (who moreover doesn't have commit
 access) shouldn't be the sole recipient of messages that are for the
 team.
 
  Oh that pissed him off. He addressed some messages to me on #e.fr
 (connecting, sending message, disconnecting, thus preventing any
 discussion from happening), stating that I had no right to commit
 without his permission, had to go through him, that it was how it
 worked and was non-negociable and that the team address was his because
 he was in charge of it.
 
  As I had no chance to discuss, as he was always disconnecting right
 after sending those messages, I sent him an e-mail, expressing my
 points of view: that I had right to contribute French translations,
 that being in my area of expertise, that never did he or anyone state
 that he was in charge and everything had to go through him, and the
 thing about the team address I stated before. I'm still waiting for a
 reply.
 
  The next day, he came to #e.fr, stating my inappropriate commit broke
 the system control dialog. Vincent and I replied that translations
 weren't to circumvent theme bugs, thanking him for the report: I said
 I'd have a look at it (true, I have yet to do that, completely forgot
 about it), which made him reply that he was doing something better:
 giving me charge of the translation, leaving immediately the project,
 and disconnected. For the record, everybody on #e.fr had been pretty
 stunned by his reaction.
  I committed a few days later a huge change, correcting many strings,
 but still leaving many untouched, as I felt I'd better be doing some
 code, and that translation could wait a little bit.
 
  Fast-forward to earlier this week, when he sent a new PO file to
 e-intl. I was actually pretty happy about it, until I had a look at
 the contents. All my corrections were gone. Everything was back to how
 they were before: hi again spelling and grammar mistakes, and welcome
 back poorly-worded sentences, which, for a nitpicker and perfectionist
 like I tend to be, are blood-tearing.
 
  I thus asked on #edevelop for people not to commit it, and sent an
 e-mail to Massimo stating the same (he did commit it anyway). I sent an
 e-mail to 

Re: [E-devel] edje multisense

2012-07-23 Thread The Rasterman
On Thu, 19 Jul 2012 13:58:29 +0200 Anisse Astier ani...@astier.eu said:

 On Wed, 18 Jul 2012 17:36:30 +0900, Carsten Haitzler (The Rasterman)
 ras...@rasterman.com wrote :
 
  On Tue, 17 Jul 2012 09:13:10 +0200 jls legalize jlslegal...@gmail.com
  said:
  
   Hi
   What do I need multisense in edje for?
   Is there any app that uses it?
   Thanks
  
  nothing uses it currently. you don't need it currently, but its the start of
  being able to have audio and haptic feedback control available in edje.
  
 Yeah. About that.
 
 I saw in edcref that since edje 1.1 you have sounds and tones. I tried
 using that for a certain terminal theme, but was only met with silence.
 
 Should I have any dependencies installed when I compile edje to have it
 playing sounds ?

correct. and they are all disabled right now for release, so even with them it
wont be enabled unless u patch the code/build. :)

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


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] bugs to clear up before release

2012-07-23 Thread The Rasterman
On Fri, 20 Jul 2012 14:02:46 -0300 Leandro Pereira lean...@profusion.mobi
said:

 On 07/20/2012 06:29 AM, Carsten Haitzler (The Rasterman) wrote:
  i have just gone through elementary test and elm has a LOAD of bugs - almost
  all of them new since last release. here is my current efl buglist in
  short: can people when they get time look at these and work on fixing
  them? :)
 
  bugs:
 
 elm - popup with items crashes

fxxred :)

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


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] Places module, mount volumes on insert

2012-07-23 Thread Nikolas Arend
Hello,

For me the places module does not mount volumes on insert, just on click 
(no problems there). I tried with different media types (thumbdrive, USB 
hd, cd rom). I'm on Fedora 17 i686.


Thanks,   Nick

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [Enlightenment-intl] problem with contributions from batden

2012-07-23 Thread Vincent Torri
On Tue, Jul 24, 2012 at 12:07 AM, Carsten Haitzler ras...@rasterman.com wrote:
 On Wed, 11 Jul 2012 21:30:50 +0200 Chidambar 'ilLogict' Zinnoury
 illog...@online.fr said:

 actually i'm getting a bit bored of no response, so... let's let things drop 
 as
 they stand right now without a response.

 here is what i say. you (illogict) have commit access. that gives you the
 ability to commit what you feel needs doing. of course like anything in a
 group/team, trampling on someone elses work is frowned upon if its bad. ie
 creates trouble. any sane person would LOVE the fact that someone - ANYONE 
 came
 along and fixed their bugs for them. bad spelling/grammar in translations are
 bugs. i'm never going to complain about that because its a nice contribution
 saving me time. i'll smile and say thanks mate!.

 imho not being able to see the positive in something like that is like
 trampling over some part of svn where you don't belong and creating trouble 
 for
 the person working there. it's just the reverse - it's stifling work.

 as for official translators - people in charge of translations. we NEVER
 officially assigned anything. stuff around here is done fairly loosely. the
 more the item (code vs theme vs translation etc.) the more careful you need to
 be as the repercussions of conflicts and issues are larger, but translations
 have fairly minimal side-effects, so it's more free.

 so since batden doesn't want to respond - here's my take. put your fixed
 version back if you believe it is better

it is better. I assure you. Even better, chidambar knows also how to
fix theme if the text does not fit well with the gui.

 than what is there now (and i do
 believe you think that). my french isn't sufficient to decide which is better
 for you :) just fix it back to where you are happy and finish off with a
 ah.. le tabernac!.

tabernac (tabarnak, actually) is french canadian, not french ;)

Vincent

 if batden wants to input on this he can do so at a
 later date, as can anyone else. :)

  Hi all.

  I'm reluctantly writing today to discuss a problem currently happening
 with Philippe Guillaumie (batden) and the French translation. I'm not
 sending this light-hearted, but because my attempts to communicate with
 him failed: I'm still waiting for a reply to my e-mail, and he's
 nowhere to be seen on IRC.

  A little bit over a month ago, a colleague of mine came to me to tell
 me about the poor state of the French translation in Enlightenment:
 some strings were undecipherable, whereas some were completely
 misleading and made him do wrong actions (especially Reboot and
 Restart Enlightenment). I then had a quick look a the file, which
 made me awe in shock by seeing the orthography and grammar mistakes,
 and moreover the poorly worded and syntaxed sentences (even on strings
 I happened to translate years ago!) They were certainly not up to the
 quality that could be expected. I thus made a quick fix for some
 strings (especially Reboot and friends), and changed at the same time
 the team's address back to enlightenment-intl from his own, as I felt
 it should be: a single individual (who moreover doesn't have commit
 access) shouldn't be the sole recipient of messages that are for the
 team.

  Oh that pissed him off. He addressed some messages to me on #e.fr
 (connecting, sending message, disconnecting, thus preventing any
 discussion from happening), stating that I had no right to commit
 without his permission, had to go through him, that it was how it
 worked and was non-negociable and that the team address was his because
 he was in charge of it.

  As I had no chance to discuss, as he was always disconnecting right
 after sending those messages, I sent him an e-mail, expressing my
 points of view: that I had right to contribute French translations,
 that being in my area of expertise, that never did he or anyone state
 that he was in charge and everything had to go through him, and the
 thing about the team address I stated before. I'm still waiting for a
 reply.

  The next day, he came to #e.fr, stating my inappropriate commit broke
 the system control dialog. Vincent and I replied that translations
 weren't to circumvent theme bugs, thanking him for the report: I said
 I'd have a look at it (true, I have yet to do that, completely forgot
 about it), which made him reply that he was doing something better:
 giving me charge of the translation, leaving immediately the project,
 and disconnected. For the record, everybody on #e.fr had been pretty
 stunned by his reaction.
  I committed a few days later a huge change, correcting many strings,
 but still leaving many untouched, as I felt I'd better be doing some
 code, and that translation could wait a little bit.

  Fast-forward to earlier this week, when he sent a new PO file to
 e-intl. I was actually pretty happy about it, until I had a look at
 the contents. All my corrections were gone. Everything was back to how
 they were before: hi again 

Re: [E-devel] [Enlightenment-intl] problem with contributions from batden

2012-07-23 Thread The Rasterman
On Tue, 24 Jul 2012 00:54:58 +0200 Vincent Torri vincent.to...@gmail.com said:

 On Tue, Jul 24, 2012 at 12:07 AM, Carsten Haitzler ras...@rasterman.com
 wrote:
  On Wed, 11 Jul 2012 21:30:50 +0200 Chidambar 'ilLogict' Zinnoury
  illog...@online.fr said:
 
  actually i'm getting a bit bored of no response, so... let's let things
  drop as they stand right now without a response.
 
  here is what i say. you (illogict) have commit access. that gives you the
  ability to commit what you feel needs doing. of course like anything in a
  group/team, trampling on someone elses work is frowned upon if its bad. ie
  creates trouble. any sane person would LOVE the fact that someone - ANYONE
  came along and fixed their bugs for them. bad spelling/grammar in
  translations are bugs. i'm never going to complain about that because its a
  nice contribution saving me time. i'll smile and say thanks mate!.
 
  imho not being able to see the positive in something like that is like
  trampling over some part of svn where you don't belong and creating trouble
  for the person working there. it's just the reverse - it's stifling work.
 
  as for official translators - people in charge of translations. we NEVER
  officially assigned anything. stuff around here is done fairly loosely. the
  more the item (code vs theme vs translation etc.) the more careful you need
  to be as the repercussions of conflicts and issues are larger, but
  translations have fairly minimal side-effects, so it's more free.
 
  so since batden doesn't want to respond - here's my take. put your fixed
  version back if you believe it is better
 
 it is better. I assure you. Even better, chidambar knows also how to
 fix theme if the text does not fit well with the gui.

yeah - so i have heard. it is better. now from 2 other french ppl other than
chidambar. i believe you. :)

  than what is there now (and i do
  believe you think that). my french isn't sufficient to decide which is
  better for you :) just fix it back to where you are happy and finish off
  with a ah.. le tabernac!.
 
 tabernac (tabarnak, actually) is french canadian, not french ;)

it is very very very french! you just don't want to admit it! :) le tabernak! :)

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


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [PATCH]Evas.h comments patch

2012-07-23 Thread The Rasterman
On Mon, 23 Jul 2012 22:40:35 +0200 Ingvaldur Sigurjonsson
rocketiii.scient...@gmail.com said:

 When reading the comments of 'evas_object_textgrid_update_add' I noticed 
 a little cnp err. The enclosed patch is just a suggestion, but the 
 misleading comment was driving me nuts...

thanks. in svn! :)

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


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: hermet IN trunk/elementary: . src/lib

2012-07-23 Thread ChunEon Park
Please someone review this patch.
This fixed clouseau pane problems.

 I don't know why did someone add the flag to scroller even it seemed it 
shouldn't be there.


-Regards, Hermet-
-Original Message-
From: Enlightenment SVNno-re...@enlightenment.org 
To: enlightenment-...@lists.sourceforge.net; 
Cc: 
Sent: 2012-07-24 (화) 11:35:25
Subject: E SVN: hermet IN trunk/elementary: . src/lib

Log:
elementary/scroller - Fixed scroller to not have the hold flag which causes the 
edje object up event block.
  
  Please review this patch I don't know the intention why did someone add this 
flags on mouse up in scroller.
  
  Anyhow I tested and works fine.
  
  

Author:   hermet
Date: 2012-07-23 19:35:25 -0700 (Mon, 23 Jul 2012)
New Revision: 74334
Trac: http://trac.enlightenment.org/e/changeset/74334

Modified:
  trunk/elementary/ChangeLog trunk/elementary/src/lib/els_scroller.c 

Modified: trunk/elementary/ChangeLog
===
--- trunk/elementary/ChangeLog2012-07-24 02:16:21 UTC (rev 74333)
+++ trunk/elementary/ChangeLog2012-07-24 02:35:25 UTC (rev 74334)
@@ -336,3 +336,7 @@
 2012-07-23  Hermet (ChunEon Park)

 * fixed invalid sd memory access when delete window inlined image
+
+2012-07-24  Hermet (ChunEon Park)
+
+* fixed scroller to not have the hold flag when mouse up happened.

Modified: trunk/elementary/src/lib/els_scroller.c
===
--- trunk/elementary/src/lib/els_scroller.c2012-07-24 02:16:21 UTC (rev 74333)
+++ trunk/elementary/src/lib/els_scroller.c2012-07-24 02:35:25 UTC (rev 74334)
@@ -2162,7 +2162,6 @@
 #else
t = ecore_loop_time_get();
 #endif
-   ev-event_flags = EVAS_EVENT_FLAG_ON_HOLD;
ax = ev-canvas.x;
ay = ev-canvas.y;
at = 0.0;
@@ -2315,10 +2314,7 @@
   sd-down.scroll = EINA_FALSE;
}
  if (sd-down.hold)
-   {
-  ev-event_flags = EVAS_EVENT_FLAG_ON_HOLD;
-  sd-down.hold = EINA_FALSE;
-   }
+   sd-down.hold = EINA_FALSE;
  sd-down.dragged_began = EINA_FALSE;
  sd-down.dir_x = EINA_FALSE;
  sd-down.dir_y = EINA_FALSE;


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Race condition

2012-07-23 Thread The Rasterman
On Mon, 23 Jul 2012 10:15:35 +0200 rustyBSD rusty...@gmx.fr said:

 Hi,
 I was told that I have to explain race conditions I found.
 
 I. Copy file bytes
 It concerns 'e_fm_op.c.diff1'. When copying a file, the dest
 file is written with bytes read from source file. It only stops
 when we are at the end of the source file. The problem
 is that you just have to launch a program like this:
 
 #include stdio.h
 #include stdlib.h
 #include string.h
 
 int main()
 {
char buf[] = a;
 
FILE* f = fopen(file.txt, wb);
if (f)
  {
while(1)
  fwrite(buf, sizeof(buf), 1, f);
  }
fclose(f);
 }
 
 And then right-click-copy 'file.txt' to another place to cause
 e to indefinitly copy the file (as it never arrives to the end
 of the file).
 
 This point is not discutable. When you copy a file, you ONLY
 must copy n bytes (got by xx.st_size) of source file. It's like
 in file transfer. You get size of file, you split it in blocks and
 send them, and you recalculate the size of the last block to
 have sent exactly the bytes of file. Otherwise, you can flood
 the server.
 
 Quick ex:
block size - 100 b
got file size - 246 b
So:
 copy 100 b
 copy 100 b
 copy 46 b
 
 That's it. The file is copied at its original size, even if it has
 changed since the copy has been started.

here i disagree.

1. if we copy a file as its downloading - we want to get the rest of the file
that was appended to after the copy began, if we can.
2. try this with cp. cp behaves like efm. if you're telling me this is a
security issue.. then it's a security issue in cp too.. and been there for a
loong time. :) (i tested it) :)
3. this is only an issue if write rates to file 1 can exceed those to file 2.
4. it cant be going on forever as eventually filesystem fills up and first file
stops filling up. :)

 II. Copy file (2 race conditions)
 When copying a simple file, we do:
 1. check type of file with stat().
 2. if dest file doesn't exist
 --  2.1 if file is a regular file, then copy.
 --  2.2 ...
 3. else: ask for overwrite
 
 There is a TOCTOU.
 
 Betwenn 2 and 3, you just have to replace the file by a symlink
 to make the copy copy the file pointed by the link.
 
 Between 1 and 2, you just have to create a symlink to the destination,
 to make the copy copy the source file in the file pointed by the symlink.
 
 You can test:
 - add 'sleep(10);' to the line 1231 of 'e_fm_op.c'
 - copy a file to an empty folder
 - create quickly a symlink in the dest folder with the same name of the
   file which will be copied, pointing to another file
 - wait... and then, check the file pointed by the symlink: its content has
   been overwritten by the source file of the copy
 
 Now, keep the sleep(), apply all patches joined to this mail, and retry.
 You will see that e doesn't copy file, because it detects that file type
 has been changed.

1. your check for type wont detect if inode/mode etc. etc. etc. match which
is actually possible given symlink vs dest file. :) so you still have your
race. it's just a bit more selective
2. the solution to this is actually to unlink then open with O_CREAT|O_EXCL. :) 
or.. O_NOFOLLOW (freebsd extn also supported in linux) :) also throw
in O_TRUNC as that's what we want in the above open will fail if someone
slipped in a file or symlink in between

 I was also told that my patches are causing problems and that there are
 no race condition (although if you test, you will see that there are),
 so I'm
 waiting for the response of raster to know what problem(s) it causes.
 
 Maxime.


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


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: hermet IN trunk/elementary: . src/lib

2012-07-23 Thread The Rasterman
On Tue, 24 Jul 2012 11:39:01 +0900 (KST) ChunEon Park her...@naver.com said:

for now let's live with it :) seems ok-ish to me. but i need to read a lot more
context...

 Please someone review this patch.
 This fixed clouseau pane problems.
 
  I don't know why did someone add the flag to scroller even it seemed it
 shouldn't be there.
 
 
 -Regards, Hermet-
 -Original Message-
 From: Enlightenment SVNno-re...@enlightenment.org 
 To: enlightenment-...@lists.sourceforge.net; 
 Cc: 
 Sent: 2012-07-24 (화) 11:35:25
 Subject: E SVN: hermet IN trunk/elementary: . src/lib
 
 Log:
 elementary/scroller - Fixed scroller to not have the hold flag which causes
 the edje object up event block. 
   Please review this patch I don't know the intention why did someone add
 this flags on mouse up in scroller. 
   Anyhow I tested and works fine.
   
   
 
 Author:   hermet
 Date: 2012-07-23 19:35:25 -0700 (Mon, 23 Jul 2012)
 New Revision: 74334
 Trac: http://trac.enlightenment.org/e/changeset/74334
 
 Modified:
   trunk/elementary/ChangeLog trunk/elementary/src/lib/els_scroller.c 
 
 Modified: trunk/elementary/ChangeLog
 ===
 --- trunk/elementary/ChangeLog2012-07-24 02:16:21 UTC (rev 74333)
 +++ trunk/elementary/ChangeLog2012-07-24 02:35:25 UTC (rev 74334)
 @@ -336,3 +336,7 @@
  2012-07-23  Hermet (ChunEon Park)
 
  * fixed invalid sd memory access when delete window inlined image
 +
 +2012-07-24  Hermet (ChunEon Park)
 +
 +* fixed scroller to not have the hold flag when mouse up happened.
 
 Modified: trunk/elementary/src/lib/els_scroller.c
 ===
 --- trunk/elementary/src/lib/els_scroller.c2012-07-24 02:16:21 UTC (rev 74333)
 +++ trunk/elementary/src/lib/els_scroller.c2012-07-24 02:35:25 UTC (rev 74334)
 @@ -2162,7 +2162,6 @@
  #else
 t = ecore_loop_time_get();
  #endif
 -   ev-event_flags = EVAS_EVENT_FLAG_ON_HOLD;
 ax = ev-canvas.x;
 ay = ev-canvas.y;
 at = 0.0;
 @@ -2315,10 +2314,7 @@
sd-down.scroll = EINA_FALSE;
 }
   if (sd-down.hold)
 -   {
 -  ev-event_flags = EVAS_EVENT_FLAG_ON_HOLD;
 -  sd-down.hold = EINA_FALSE;
 -   }
 +   sd-down.hold = EINA_FALSE;
   sd-down.dragged_began = EINA_FALSE;
   sd-down.dir_x = EINA_FALSE;
   sd-down.dir_y = EINA_FALSE;
 
 
 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and 
 threat landscape has changed and how IT managers can respond. Discussions 
 will include endpoint security, mobile security and the latest in malware 
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 enlightenment-svn mailing list
 enlightenment-...@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and 
 threat landscape has changed and how IT managers can respond. Discussions 
 will include endpoint security, mobile security and the latest in malware 
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


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


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] DBus/Elm Application Question.

2012-07-23 Thread Nick Hughart
Alright, so I'm working on a PolicyKit1 authentication agent and have
run into something of a problem.  I am working on implementing this
dbus method:

http://hal.freedesktop.org/docs/polkit/eggdbus-interface-org.freedesktop.PolicyKit1.AuthenticationAgent.html#eggdbus-method-org.freedesktop.PolicyKit1.AuthenticationAgent.BeginAuthentication

I am unmarshaling the command and all that just fine inside a callback
function that was specified in when setting up BeginAuthentication via
e_dbus_interface_method_add. 

The problem is that I have to somehow popup a window to authenticate
the user before calling AuthenticationAgentResponse and also before I
send the reply for BeginAuthentication.

Given that while I'm in the callback, the elm main loop will not be
running, I'm not sure how to popup the dialog without returning from
the callback and thus replying to the dbus message before making the
call to AuthenticationAgentResponse().

Will I need to fork off a process to do the GUI part of the app while
leaving another process to do the DBus communication or is there
something I'm missing?

Been hoping to see some dbus gurus in #edevel, but seems I keep
missing them so hoping someone can enlighten me :)

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] [PATCH] FIx wrong frame calculation in evas_object_resize()

2012-07-23 Thread yan . wang
Hi,
  I found some bugs which come from the difference of frame processing
between X and Wayland:
  http://trac.enlightenment.org/e/ticket/1024
  http://trac.enlightenment.org/e/ticket/1193
  As you know, window client area is smaller in Wayland engine because
elementary has to keep frame space. But  evas_object_resize() reduces frame
space for every widget. This is wrong. It causes widget height is
subtracted
to negative and couldn't be display because its condition isn't enough
only by checking obj-smart-parent. So I add one condition
strcmp(obj-type, elm_win) == 0 for making sure only elm_win do frame
calculation. Please review evas_object_resize_frame.patch.
  It also need calling evas_object_move() once for re-calculating widget
position based on frame space. (label_example_moving.patch)
  But because smaller window client area couldn't keep all content (e.g.
text of all labels in label_example_01) of window like X. Otherwise, it is
also OK to enlarge elm_win size for wayland engine specially in
label_example_01.c. But this will make application code different
between X and Wayland. it may not make sense because platform engine
dependency.
  It may be better to enlarge (not reduce) window size in elm_win
construction/layout/rendering and keep the same size of window client area
with X. Frame will be drawn on additional area. But it means modify
current elm_win construction/layout/rendering mechanism. So we may have to
convince community and need more time to implement it because it is a big
change.
  Which path is better choice? At least, evas_object_resize_frame.patch
may be temp solution for workaround.
  Thanks.

Yan Wang



Index: src/lib/canvas/evas_object_main.c
===
--- src/lib/canvas/evas_object_main.c	(revision 74333)
+++ src/lib/canvas/evas_object_main.c	(working copy)
@@ -683,7 +683,7 @@ evas_object_resize(Evas_Object *obj, Evas_Coord w,
 int fw, fh;
 
 evas_output_framespace_get(obj-layer-evas, NULL, NULL, fw, fh);
-if (!obj-smart.parent)
+if (!obj-smart.parent  strcmp(obj-type, elm_win) == 0)
   {
  nw = w - fw;
  nh = h - fh;Index: src/examples/label_example_01.c
===
--- src/examples/label_example_01.c	(revision 74333)
+++ src/examples/label_example_01.c	(working copy)
@@ -25,6 +25,7 @@ elm_main(int argc, char **argv)
elm_label_slide_set(label, EINA_TRUE);
elm_object_style_set(label, slide_bounce);
evas_object_resize(label, 200, 15);
+   evas_object_move(label, 0, 0);
evas_object_show(label);
 
label2 = elm_label_add(win);--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: raster IN trunk/evas: . src/lib/canvas

2012-07-23 Thread Vincent Torri
On Tue, Jul 24, 2012 at 6:59 AM, Enlightenment SVN
no-re...@enlightenment.org wrote:
 Log:
 fix long standing layer set bug



 Author:   raster
 Date: 2012-07-23 21:59:22 -0700 (Mon, 23 Jul 2012)
 New Revision: 74342
 Trac: http://trac.enlightenment.org/e/changeset/74342

 Modified:
   trunk/evas/ChangeLog trunk/evas/src/lib/canvas/evas_layer.c

 Modified: trunk/evas/ChangeLog
 ===
 --- trunk/evas/ChangeLog2012-07-24 04:35:08 UTC (rev 74341)
 +++ trunk/evas/ChangeLog2012-07-24 04:59:22 UTC (rev 74342)
 @@ -908,6 +908,7 @@
  2012-07-24  Ingvaldur Sigurjonsson

 * Fix typoe in docs
 + .mine

  2012-07-24  Hermet (ChunEon Park)

conflict ?

Vincent

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] window size mechanism on wayland question

2012-07-23 Thread Juan Zhao
Hi,
  Just double confirm that: on wayland, if the window resized to (300,
200), and the real size of the window is (300, 200-frameheight).If the
frameheight is 26, then the size of the window will be (300, 200).
  On Xorg, the frame will be added by the compositor, so we did not meet
this condition.
  On wayland toytoolkit, the toytookit will add the frame, the app
itself should not consider the frame related issues.
  Is this a bug to fix in efl? 

Thanks,
Juan


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel