Re: [E-devel] DBus/Elm Application Question.

[Michael Blumenkrantz]

this is one of the (many) (huge) issues with current e_dbus, and a reason
why it must be completely scrapped in the future. in order to achieve the
functionality you are looking for, you basically have two options:
1) recursive main loops
2) block in this thread, fork and pipe to get the result

either way sucks and is not recommended.

On Tue, Jul 24, 2012 at 4:36 AM, Nick Hughart  wrote:

> 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
>
--
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] [Ejde, Elementary] changed how to select texts in an EXPLICIT mode entry

[Myung-Jae Lee]

Dear all,

In an EXPLICIT mode entry there are some uncomfortable things when we try to 
copy & paste texts.
such as,
- Entering select mode is possible only after we long-press entry and press 
'select' item in a hoversel menu.
- Even we entered the select mode there's no change in an entry, so that makes 
people who uses EXPLICIT mode entry for the first time confused.

Therefore, I'd like to enhance the EXPLICIT mode entry like below.
- When we entered the select mode by pressing 'select' menu, select a word near 
a cursor automatically.
- Double click and triple click trigers select mode to an EXPLICIT mode entry, 
too.
- Even the selection block exists after 'copy' menu is clicked, extending the 
selection is not possible currently. (Is it a bug?... I changed this.)

I attached the patch files related to above changes.
Please review these and feel free to give me feedbacks when you have questions.

Regards,
--
Myungjae Lee

elm_entry.wordselecting.patch
Description: Binary data


edje_entry.wordselecting.patch
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

[E-devel] window size mechanism on wayland question

[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

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

[Vincent Torri]

On Tue, Jul 24, 2012 at 6:59 AM, Enlightenment SVN
 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] [PATCH] FIx wrong frame calculation in evas_object_resize()

[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

[E-devel] DBus/Elm Application Question.

[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

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

[The Rasterman]

On Tue, 24 Jul 2012 11:39:01 +0900 (KST) ChunEon Park  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 SVN" 
> To: ; 
> 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

Re: [E-devel] Race condition

[The Rasterman]

On Mon, 23 Jul 2012 10:15:35 +0200 rustyBSD  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 
> #include 
> #include 
> 
> 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

[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 SVN" 
To: ; 
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] [PATCH]Evas.h comments patch

[The Rasterman]

On Mon, 23 Jul 2012 22:40:35 +0200 Ingvaldur Sigurjonsson
 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] [Enlightenment-intl] problem with contributions from batden

[The Rasterman]

On Tue, 24 Jul 2012 00:54:58 +0200 Vincent Torri  said:

> On Tue, Jul 24, 2012 at 12:07 AM, Carsten Haitzler 
> wrote:
> > On Wed, 11 Jul 2012 21:30:50 +0200 Chidambar 'ilLogict' Zinnoury
> >  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] [Enlightenment-intl] problem with contributions from batden

[Vincent Torri]

On Tue, Jul 24, 2012 at 12:07 AM, Carsten Haitzler  wrote:
> On Wed, 11 Jul 2012 21:30:50 +0200 Chidambar 'ilLogict' Zinnoury
>  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 h

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

[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] bugs to clear up before release

[The Rasterman]

On Fri, 20 Jul 2012 14:02:46 -0300 Leandro Pereira 
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

Re: [E-devel] edje multisense

[The Rasterman]

On Thu, 19 Jul 2012 13:58:29 +0200 Anisse Astier  said:

> On Wed, 18 Jul 2012 17:36:30 +0900, Carsten Haitzler (The Rasterman)
>  wrote :
> 
> > On Tue, 17 Jul 2012 09:13:10 +0200 jls legalize 
> > 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] [Enlightenment-intl] problem with contributions from batden

[The Rasterman]

On Wed, 11 Jul 2012 21:30:50 +0200 Chidambar 'ilLogict' Zinnoury
 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 t

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

[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] [PATCH] evas/wayland_egl: Fix segfault when doing alpha setting in elmentary.

[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 
> 
> 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 =

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

[ChunEon Park]

yes.. certainly, scroller.


Pending to tomorrow.




-Regards, Hermet-

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

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

[zhiwen . wu]

From: Alex Wu 

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,
-

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

[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
>  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

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

[The Rasterman]

On Fri, 20 Jul 2012 14:02:46 -0300 Leandro Pereira 
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] [patch] Link copying fix

[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  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

[E-devel] Race condition

[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 
#include 
#include 

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 
 #include 
 
+#include 
+
 #include 
 #include 
 
@@ -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 writing: %s.", task

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

[The Rasterman]

On Fri, 20 Jul 2012 22:43:21 +0200 rustyBSD  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