[EGIT] [core/enlightenment] master 01/01: remove "border_raise_on_focus" config option
discomfitor pushed a commit to branch master.
http://git.enlightenment.org/core/enlightenment.git/commit/?id=f1a65ee922c5f937cd9ab9318c5142e2e4dfccef
commit f1a65ee922c5f937cd9ab9318c5142e2e4dfccef
Author: Mike Blumenkrantz
Date: Mon Oct 7 06:49:33 2013 +0100
remove "border_raise_on_focus" config option
buckle up. for the first time in history, a config option is getting
removed instead of added.
the reasons for this removal are many, but let's go way back to the
beginning and see why it was added:
oh wait, we can't because the commit message (from 2006) is
>>patches that i said were in - commit. (see my reply emails)
>>also finish off a TODO item or 2
reading through the TODO items which were also crossed off in that commit,
I'm assuming that this was the "option to NOT raise on focus in click to focus"
item.
== REASON 1 ==
the problem here is that there's another, BETTER option called "click
raises window" (always_click_to_raise) which does the same thing, except it
doesn't totally fuck you when you get a random X focus event, which happens
more often than you might think.
this means that, to avoid broken behavior which might cause your windows to
spastically raise for a few frames in common cases (using winlist...) with
click-to-focus, you have to know that this is the default-enabled option that's
fucking you, and you have to remember to manually disable it every time. if you
DON'T know that this is the option that's fucking you, and you just see windows
randomly raising on their own, you'll probably either ignore it or file a bug,
when this is suppos [...]
== REASON 2 ==
there's also auto-raise, which can be set to 0.0s, which is effectively the
same thing since it also triggers on focus but can be configured not to fuck
your window stack
== REASON 3 ==
aaand finally, this option makes any sort of pointer focus model impossible
to use, since your windows will constantly be raising all over as you move the
mouse
tl;dr: I'm removing it, e-dealwithit.gif
---
ChangeLog | 4
NEWS | 1 +
config/default/e.src | 1 -
config/mobile/e.src | 1 -
config/standard/e.src | 1 -
src/bin/e_config.c| 2 --
src/bin/e_config.h| 1 -
src/bin/e_configure_option.c | 1 -
src/bin/e_focus.c | 10 +-
src/bin/e_msgbus.c| 7 +--
src/modules/conf_window_manipulation/e_int_config_focus.c | 9 +
src/modules/wizard/page_060.c | 2 --
12 files changed, 8 insertions(+), 32 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 3815b9b..86c6cff 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2013-10-07 Mike Blumenkrantz
+
+* removed "raise on focus" config option
+
2013-10-03 Mike Blumenkrantz
* Fix filemanager spring window closing when dragging from desktop
diff --git a/NEWS b/NEWS
index ea07223..dcb8ec5 100644
--- a/NEWS
+++ b/NEWS
@@ -80,6 +80,7 @@ Deprecations:
Removed:
* e_manager_comp namespace
* HAL support for filemanager
+* "raise on focus" config option
Improvements:
* mixer shows more channels when using alsa subsystem and correctly
disable controls
diff --git a/config/default/e.src b/config/default/e.src
index 43c91ec..458f643 100644
--- a/config/default/e.src
+++ b/config/default/e.src
@@ -160,7 +160,6 @@ group "E_Config" struct {
value "mouse_accel_denominator" int: 1;
value "mouse_accel_threshold" int: 4;
value "border_raise_on_mouse_action" int: 1;
- value "border_raise_on_focus" int: 1;
value "desk_flip_wrap" int: 0;
value "fullscreen_flip" int: 1;
value "icon_theme" string: "Tango";
diff --git a/config/mobile/e.src b/config/mobile/e.src
index ff03024..a60c517 100644
--- a/config/mobile/e.src
+++ b/config/mobile/e.src
@@ -148,7 +148,6 @@ group "E_Config" struct {
value "mouse_accel_denominator" int: 1;
value "mouse_accel_threshold" int: 4;
value "border_raise_on_mouse_action" int: 1;
-value "border_raise_on_focus" int: 1;
value "desk_flip_wrap" int: 0;
value "fullscreen_flip" int: 1;
value "icon_theme" string: "Tango";
diff --git a/config/standard/e.src b/config/standard/e.src
index f6d6e38..d834c8a 100644
--- a/config/standard/e.src
+++ b/config/standard/e.src
@@ -149,7 +149,6 @@ group "E_Config" struct {
value "mouse_accel_denominator" int: 1;
value "mouse_accel_threshold" int: 4;
value "border_raise_on_mouse_action" int: 1;
-value "border_raise_on_focus" int: 0;
value "desk_fli
Re: [E-devel] [EGIT] [core/efl] master 01/01: eina/eina_file - fix eina_file_map_lines() to not drop of one character in the last line.
ok, thanks. I will add the test case soon, also. -Regards, Hermet- -Original Message- From: "Cedric BAIL" To: "Enlightenment developer list"; Cc: Sent: 2013-10-04 (금) 11:03:13 Subject: Re: [E-devel] [EGIT] [core/efl] master 01/01: eina/eina_file - fix eina_file_map_lines() to not drop of one character in the last line. On Thu, Oct 3, 2013 at 6:58 PM, ChunEon Park @hermet.pe.kr> wrote: > hermet pushed a commit to branch master. > > http://git.enlightenment.org/core/efl.git/commit/?id=18be4c50d9990c82ed9ce4269b7820e61f772699 > > commit 18be4c50d9990c82ed9ce4269b7820e61f772699 > Author: ChunEon Park @hermet.pe.kr> > Date: Fri Oct 4 01:58:35 2013 +0900 > > eina/eina_file - fix eina_file_map_lines() to not drop of one character > in the last line. That remember me that with eina_file_virtualize we should be able to have easier test for those case. If anyone as the time to write small test case for eina_file, you are more than welcome. Maybe I will have some times one of this days... > --- > ChangeLog4 > NEWS 1 + > src/lib/eina/eina_file_common.c 3 ++- > 3 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/ChangeLog b/ChangeLog > index 2444fdb..cb4ea4e 100644 > --- a/ChangeLog > +++ b/ChangeLog > @@ -1,3 +1,7 @@ > +2013-10-04 ChunEon Park (Hermet) > + > + * Eina: fix eina_file_map_lines() to not drop of one character in the > last line. > + > 2013-10-02 Cedric Bail > > * Eina: add eina_swap16(), eina_swap32(), eina_swap64(). > diff --git a/NEWS b/NEWS > index cd3d9f2..fc83666 100644 > --- a/NEWS > +++ b/NEWS > @@ -258,6 +258,7 @@ Fixes: > - Fix memory leak in eina_xattr_value_ls. > - Fix magic failure in eina_value_array_count when array has not been > allocated. > - Fix issue when wchar_t is signed and eina_unicode does negative array > lookups. > + - Eina: fix eina_file_map_lines() to not drop of one character in the > last line. > * Eet: > - Fix PPC (big endian) image codec bug. > - Fix leak in eet_pbkdf2_sha1 with OpenSSL. > diff --git a/src/lib/eina/eina_file_common.c b/src/lib/eina/eina_file_common.c > index 5d7ef11..ec9cac8 100644 > --- a/src/lib/eina/eina_file_common.c > +++ b/src/lib/eina/eina_file_common.c > @@ -543,7 +543,8 @@ _eina_file_map_lines_iterator_next(Eina_Lines_Iterator > *it, void **data) > it->current.start = it->current.end; > > it->current.end = eol; > - it->current.length = eol - it->current.start - 1; > + it->current.length = eol - it->current.start; > + if (eol < it->end) it->current.length--; > > *data = &it->current; > return EINA_TRUE; > > -- > > > -- Cedric BAIL -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Wayland and subsurfaces
On Sun, Oct 6, 2013 at 9:04 AM, Chris Michael wrote: > On 10/06/13 06:11, Cedric BAIL wrote: >> On Sat, Oct 5, 2013 at 12:05 AM, Rafael Antognolli >> wrote: >>> Example usage of what I have just committed (fixes and improvements >>> for Evas_Video_Surface, and added Ecore_Wl_Subsurf) here: >>> >>> https://github.com/antognolli/buffer_object >>> >>> This is a helper, or a skeleton, for creating and setting up the image >>> object that would be used with the buffers. It can be made more >>> generic if necessary, thus allowing to use both Wayland buffers or X >>> stuff. The code itself is inside buffer_object.c. Sample usage is >>> inside main.c. >> That's exactly the direction where I wanted to get that code. Really >> nice patch, thanks. The next improvement I was looking for was to use >> somehow the pixels buffer directly when using OpenGL (zero copy >> scheme), by looking at your code I do think than in compositing mode >> we are still doing a copy. Am i right ? >> >>> Anyway, this can be added somewhere in EFL, I just don't know exactly >>> where would be the best place... ideas? >> That is indeed a good question. I guess the first place to use this is >> somewhere in Emotion's gstreamer backend. I would even prefer to see >> that feature working with VLC backend, but I don't think there is a >> way to make vlc output the pixels in a wayland surface. > Not currently :( And I would not count on one anytime soon :( > > https://trac.videolan.org/vlc/ticket/7936 > > Although, if we had the pixels (I don't know the VLC code too well) then > we should be able to slap those into a surface... Well, in the generic backend, we create the pixel buffer where VLC is going to decode the video, right? So it's basically the same, we could create a wl_buffer and let VLC write on it, and then we display that as a subsurface if possible. I was also thinking that if we add YUV as a buffer format for wl_buffer (it's missing that so far), then VLC can write the pixels in YUV format, and we let the "composition" of the subsurface + main surface to the compositor, and that would speed up things, wouldn't it? >> Also the >> gstreamer backend is easier to integrate as it doesn't require to >> communicate with another process to get the pixels (Not really a win >> in my opinion, but in this case will make life easier). wl_buffer can be (maybe *must* be) a shm buffer, so that should be easy to handle even in vlc, I think. >> Also I have been starting to think that maybe we should have a simpler >> layer than Emotion that does all this buffer management and his used >> by Emotion. That's just a though right now. > > > -- > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Rafael Antognolli -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/elementary] master 01/01: elementary/scroller - set the NULL to not access dangling pointer after deleting animator.
no problem .
-Regards, Hermet-
-Original Message-
From: "Daniel Juyung Seo"
To: "Enlightenment developer list";
Cc: ;
Sent: 2013-10-07 (월) 00:24:32
Subject: Re: [E-devel] [EGIT] [core/elementary] master 01/01:
elementary/scroller - set the NULL to not access dangling pointer after
deleting animator.
Oops. Sorry it's my bad.
Thanks for the fix.
Daniel Juyung Seo (SeoZ)
On Sun, Oct 6, 2013 at 11:36 PM, ChunEon Park @hermet.pe.kr> wrote:
> hermet pushed a commit to branch master.
>
>
> http://git.enlightenment.org/core/elementary.git/commit/?id=e9ee16a88a80f3fe929f91494ae462b280fa861c
>
> commit e9ee16a88a80f3fe929f91494ae462b280fa861c
> Author: ChunEon Park @hermet.pe.kr>
> Date: Sun Oct 6 23:35:51 2013 +0900
>
> elementary/scroller - set the NULL to not access dangling pointer
> after deleting animator.
> ---
> src/lib/elm_interface_scrollable.c 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/lib/elm_interface_scrollable.c
> b/src/lib/elm_interface_scrollable.c
> index cfa76e0..2cbb0c9 100644
> --- a/src/lib/elm_interface_scrollable.c
> +++ b/src/lib/elm_interface_scrollable.c
> @@ -1463,7 +1463,7 @@
> _elm_scroll_bounce_eval(Elm_Scrollable_Smart_Interface_Data *sid)
>{
> if (sid->bouncemex)
> {
> - if (sid->scrollto.x.animator)
> ecore_animator_del(sid->scrollto.x.animator);
> + ELM_SAFE_FREE(sid->scrollto.x.animator,
> ecore_animator_del);
>sid->down.bounce_x_animator =
> ecore_animator_add(_elm_scroll_bounce_x_animator,
> sid->obj);
>sid->down.anim_start2 = ecore_loop_time_get();
> @@ -1483,7 +1483,7 @@
> _elm_scroll_bounce_eval(Elm_Scrollable_Smart_Interface_Data *sid)
>{
> if (sid->bouncemey)
> {
> - if (sid->scrollto.y.animator)
> ecore_animator_del(sid->scrollto.y.animator);
> + ELM_SAFE_FREE(sid->scrollto.y.animator,
> ecore_animator_del);
>sid->down.bounce_y_animator =
> ecore_animator_add(_elm_scroll_bounce_y_animator,
> sid->obj);
>sid->down.anim_start3 = ecore_loop_time_get();
>
> --
>
>
>
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Wayland and subsurfaces
On Sun, Oct 6, 2013 at 2:11 AM, Cedric BAIL wrote: > On Sat, Oct 5, 2013 at 12:05 AM, Rafael Antognolli > wrote: >> Example usage of what I have just committed (fixes and improvements >> for Evas_Video_Surface, and added Ecore_Wl_Subsurf) here: >> >> https://github.com/antognolli/buffer_object >> >> This is a helper, or a skeleton, for creating and setting up the image >> object that would be used with the buffers. It can be made more >> generic if necessary, thus allowing to use both Wayland buffers or X >> stuff. The code itself is inside buffer_object.c. Sample usage is >> inside main.c. > > That's exactly the direction where I wanted to get that code. Really > nice patch, thanks. The next improvement I was looking for was to use > somehow the pixels buffer directly when using OpenGL (zero copy > scheme), by looking at your code I do think than in compositing mode > we are still doing a copy. Am i right ? Cool, thanks. And well, I am not sure, but I think there was an optimization that would allow to use the pixels directly when doing an image_data_set, which is basically what I am doing. By "compositing mode" you mean with or without the subsurface? >> Anyway, this can be added somewhere in EFL, I just don't know exactly >> where would be the best place... ideas? > > That is indeed a good question. I guess the first place to use this is > somewhere in Emotion's gstreamer backend. I would even prefer to see > that feature working with VLC backend, but I don't think there is a > way to make vlc output the pixels in a wayland surface. Also the > gstreamer backend is easier to integrate as it doesn't require to > communicate with another process to get the pixels (Not really a win > in my opinion, but in this case will make life easier). > > Also I have been starting to think that maybe we should have a simpler > layer than Emotion that does all this buffer management and his used > by Emotion. That's just a though right now. -- Rafael Antognolli -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: default clock gadget config is now digital with seconds display disabled
On Sun, 06 Oct 2013 20:01:42 -0700 Mike Blumenkrantz wrote: > discomfitor pushed a commit to branch master. > > http://git.enlightenment.org/core/enlightenment.git/commit/?id=54055e41258e58e4abe67eaa005e2b00fe570c11 > > commit 54055e41258e58e4abe67eaa005e2b00fe570c11 > Author: Mike Blumenkrantz > Date: Mon Oct 7 04:01:29 2013 +0100 > > default clock gadget config is now digital with seconds display > disabled > I've never seen anyone use the analog clock, so this should save > people some time when adding new clocks on their screen I think I've pointed out before, I use the analogue clock. Not objecting to this change though. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/enlightenment] master 03/03: fix annoying gadman crash when plugging screens
discomfitor pushed a commit to branch master.
http://git.enlightenment.org/core/enlightenment.git/commit/?id=3c343db3494f7cbd77013ed993cea8eb7485350b
commit 3c343db3494f7cbd77013ed993cea8eb7485350b
Author: Mike Blumenkrantz
Date: Mon Oct 7 04:18:26 2013 +0100
fix annoying gadman crash when plugging screens
---
src/modules/gadman/e_mod_gadman.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/modules/gadman/e_mod_gadman.c
b/src/modules/gadman/e_mod_gadman.c
index add0eef..ea6bc69 100644
--- a/src/modules/gadman/e_mod_gadman.c
+++ b/src/modules/gadman/e_mod_gadman.c
@@ -1653,8 +1653,8 @@ _e_gadman_cb_zone_change(void *data __UNUSED__, int type,
void *event)
{
if (e_gadcon_zone_get(gc) != ev->zone) continue;
e_object_del(E_OBJECT(gc));
- if (!Man->gadcons[layer])
-E_FREE_FUNC(Man->movers[layer], evas_object_del);
+ Man->gadcons[layer] =
eina_list_remove_list(Man->gadcons[layer], l);
+ E_FREE_FUNC(Man->movers[layer], evas_object_del);
break;
}
}
--
[EGIT] [core/enlightenment] master 01/03: remove gadcons from custom populate job during deletion
discomfitor pushed a commit to branch master. http://git.enlightenment.org/core/enlightenment.git/commit/?id=4446442163b6a4393460ee137902be0192ae0324 commit 4446442163b6a4393460ee137902be0192ae0324 Author: Mike Blumenkrantz Date: Mon Oct 7 04:15:18 2013 +0100 remove gadcons from custom populate job during deletion this showed up on my valgrind radar while xrandring, so it's safety time --- src/bin/e_gadcon.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/bin/e_gadcon.c b/src/bin/e_gadcon.c index 919ec72..6e5cfff 100644 --- a/src/bin/e_gadcon.c +++ b/src/bin/e_gadcon.c @@ -2011,6 +2011,8 @@ _e_gadcon_free(E_Gadcon *gc) gadcons = eina_list_remove(gadcons, gc); } eina_list_free(gc->populated_classes); + if (custom_populate_requests) + custom_populate_requests = eina_list_remove(custom_populate_requests, gc); if (gc->o_container) evas_object_del(gc->o_container); eina_stringshare_del(gc->name); eina_stringshare_del(gc->edje.swallow_name); --
[EGIT] [core/enlightenment] master 02/03: cosmetic variable declaration movement
discomfitor pushed a commit to branch master.
http://git.enlightenment.org/core/enlightenment.git/commit/?id=8956de3359f13ca5c57a02ab0c8f8ae0a0e69b51
commit 8956de3359f13ca5c57a02ab0c8f8ae0a0e69b51
Author: Mike Blumenkrantz
Date: Mon Oct 7 04:16:24 2013 +0100
cosmetic variable declaration movement
---
src/modules/gadman/e_mod_gadman.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/modules/gadman/e_mod_gadman.c
b/src/modules/gadman/e_mod_gadman.c
index c1c4e07..add0eef 100644
--- a/src/modules/gadman/e_mod_gadman.c
+++ b/src/modules/gadman/e_mod_gadman.c
@@ -1627,9 +1627,8 @@ static Eina_Bool
_e_gadman_cb_zone_change(void *data __UNUSED__, int type, void *event)
{
E_Gadcon *gc;
- Eina_List *l;
+ Eina_List *l, *ll;
E_Event_Zone_Move_Resize *ev = event;
- Eina_List *ll;
const char *layer_name[] = {"gadman", "gadman_top"};
int layer;
E_Gadcon_Client *gcc;
--
[EGIT] [core/enlightenment] master 01/01: default clock gadget config is now digital with seconds display disabled
discomfitor pushed a commit to branch master. http://git.enlightenment.org/core/enlightenment.git/commit/?id=54055e41258e58e4abe67eaa005e2b00fe570c11 commit 54055e41258e58e4abe67eaa005e2b00fe570c11 Author: Mike Blumenkrantz Date: Mon Oct 7 04:01:29 2013 +0100 default clock gadget config is now digital with seconds display disabled I've never seen anyone use the analog clock, so this should save people some time when adding new clocks on their screen next step: make the clock able to do timezones... --- src/modules/clock/e_mod_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/modules/clock/e_mod_main.c b/src/modules/clock/e_mod_main.c index 5063b88..b234de1 100644 --- a/src/modules/clock/e_mod_main.c +++ b/src/modules/clock/e_mod_main.c @@ -756,9 +756,9 @@ _conf_item_get(const char *id) ci->weekend.start = 6; ci->weekend.len = 2; ci->week.start = 1; - ci->digital_clock = 0; + ci->digital_clock = 1; ci->digital_24h = 0; - ci->show_seconds = 1; + ci->show_seconds = 0; ci->show_date = 0; clock_config->items = eina_list_append(clock_config->items, ci); --
[EGIT] [core/enlightenment] master 01/01: wl_desktop_shell -> whitelisted
discomfitor pushed a commit to branch master. http://git.enlightenment.org/core/enlightenment.git/commit/?id=c2b8ec2e0323ca9c720a88fc49973e48cd24cc7e commit c2b8ec2e0323ca9c720a88fc49973e48cd24cc7e Author: Mike Blumenkrantz Date: Mon Oct 7 03:54:24 2013 +0100 wl_desktop_shell -> whitelisted --- src/bin/e_module.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/bin/e_module.c b/src/bin/e_module.c index fc901cb..aa92878 100644 --- a/src/bin/e_module.c +++ b/src/bin/e_module.c @@ -897,6 +897,7 @@ _e_module_whitelist_check(void) "wl_drm", "wl_screenshot", "wl_shell", + "wl_desktop_shell", "xkbswitch", "echievements", "music-control", --
[EGIT] [core/enlightenment] master 01/01: add minor optimization for e_manager_current_get for most common case
discomfitor pushed a commit to branch master.
http://git.enlightenment.org/core/enlightenment.git/commit/?id=5fb09a0249f714ab185b1f84a024d3f468963dd6
commit 5fb09a0249f714ab185b1f84a024d3f468963dd6
Author: Mike Blumenkrantz
Date: Mon Oct 7 03:52:09 2013 +0100
add minor optimization for e_manager_current_get for most common case
there's only more than one manager when we're running true multi-head,
which is pretty rare/non-existent with compositing, so we can avoid an X call
here by just returning the only possible manager
---
src/bin/e_manager.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/bin/e_manager.c b/src/bin/e_manager.c
index 7dca2be..3d167cd 100644
--- a/src/bin/e_manager.c
+++ b/src/bin/e_manager.c
@@ -455,6 +455,8 @@ e_manager_current_get(void)
int x, y;
if (!managers) return NULL;
+ if (eina_list_count(managers) == 1)
+ return eina_list_data_get(managers);
EINA_LIST_FOREACH(managers, l, man)
{
ecore_x_pointer_xy_get(man->win, &x, &y);
--
Re: [E-devel] Git, merges, and better work-flows
On 2013-10-06 23:47, Tom Hacohen wrote: > Yeah, you can delete the remote branch after merging to master. > > The trick here is that we don't send emails about commits in dev > branches > and we don't send emails about commits that were merged into master > from a > dev branch (that is, commits that have already existed in the repo at > the > time of the push). Pushing to a dev branch first will thus prevent the > emails from being sent. Maybe this trick is handled by the multi mail hook, but post-receive will be constructed that way : #1 push to own branch refs/heads/dev/XX/YY #2 push the merge to master refs/heads/master So in the case of original seojuyung2 00141eb19a879c64d24e773d0dec6e6440ad6c51 refs/heads/dev/seojuyung2/YY d9e81284369edad30f9225d86f1959c6901e87d8 ad8a00cf343786497f12ef6efc1c1de38d363196 refs/heads/master The second is still 60 commit difference, so I'm not so sure there will be no mail storm again. This will not happen is case multimail hook save somewhere what sha1 have already been announced, but I don't believe it's the case atm. beber > On Sun, Oct 6, 2013 at 5:09 PM, Daniel Juyung Seo > wrote: > >> But that will create a remote branch which is not needed for others. >> Or I can delete the remote branch after merging to master. Is that ok? >> >> Daniel Juyung Seo (SeoZ) >> >> >> On Sun, Oct 6, 2013 at 12:36 AM, Tom Hacohen wrote: >> >> > Well. There's a way to avoid that: If you push to a remote branch before >> > merging, there will be no tsunami. A mail will only be sent to the merge >> > commit. >> > >> > >> > On Sat, Oct 5, 2013 at 4:05 PM, Daniel Juyung Seo > > >wrote: >> > >> > > I thought the same as David Seikel :) >> > > That's why the commit tsunami happened. >> > > >> > > Anyhow, it's same as before except we now allow merge commit for some >> > > cases. >> > > >> > > Daniel Juyung Seo (SeoZ) >> > > >> > > On Sat, Oct 5, 2013 at 8:09 PM, Tom Hacohen wrote: >> > > >> > > > No. The point is not to squash them, but have one cover-letter commit >> > > that >> > > > holds them all. If you "git log --first-parent" you won't see all the >> > > > commits, just the merge commit that describes the whole changeset. >> > > > >> > > > >> > > > On Sat, Oct 5, 2013 at 10:36 AM, David Seikel >> > wrote: >> > > > >> > > > > On Sat, 5 Oct 2013 17:58:17 +0900 Daniel Juyung Seo >> > > > > wrote: >> > > > > >> > > > > > On Fri, Oct 4, 2013 at 11:48 PM, Tom Hacohen >> > > > > > wrote: >> > > > > > >> > > > > > > On 04/10/13 15:40, Michael Blumenkrantz wrote: >> > > > > > > > On Fri, 04 Oct 2013 15:18:46 +0100 >> > > > > > > > Tom Hacohen wrote: >> > > > > > > > >> > > > > > > >> On 02/10/13 16:17, Tom Hacohen wrote: >> > > > > > > >>> Hey guys, >> > > > > > > >>> >> > > > > > > >>> I would like to suggest a new work-flow. This work-flow >> will >> > > > > > > >>> not be mandatory, but just an allowed alternative to the >> > > > > > > >>> current "commit to master" approach. >> > > > > > > >>> >> > > > > > > >>> At the moment we do not allow merges, at all. This was to >> > > > > > > >>> prevent >> > > > > > > people >> > > > > > > >>> from littering the log with their inability to rebase (git >> > pull >> > > > > > > >>> --rebase) their local changes on top of the existing >> commits. >> > > > > > > >>> This will still remain the same. I'd like to suggest using >> > > > > > > >>> merges to our >> > > > > > > advantage. >> > > > > > > >>> >> > > > > > > >>> I suggest the following: >> > > > > > > >>> For fixes, small features, and the like, do the same as you >> > do >> > > > > > > >>> now. Commit and push to master. >> > > > > > > >>> >> > > > > > > >>> For bigger features, rewrites, or any form of a few commits >> > > > > > > >>> that are tied together by being part of the same set, do as >> > > > > > > >>> follows (it's obviously simpler than that, I listed >> > everything >> > > > > > > >>> to over-simplify >> > > > > > > things): >> > > > > > > >>> 1. Create a branch (either local or remote) for your >> change. >> > > > > > > >>> 2. Work on that branch. >> > > > > > > >>> 3. When ready, instead of pushing to master: >> > > > > > > >>> 3. rebase over master (git fetch; git rebase >> origin/master). >> > > > > > > >>> 4. switch to master (git checkout master) >> > > > > > > >>> 6. git merge --no-ff your-feature-branch-name >> > > > > > > >>> 7. Describe your feature in the commit message. >> > > > > > > >>> 8. push to master (git push or git push origin master). >> > > > > > > >>> >> > > > > > > >>> I've done a few example commits on >> > > > > > > >>> >> > > > https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ >> > > > > > > >>> >> > > > > > > >>> This work-flow lets us have linear history, while having >> > > > > > > >>> feature-sets show as a single merge that can easily be >> > > > > > > >>> reverted, provide a good description about a feature and >> the
Re: [E-devel] [EGIT] [core/efl] master 01/01: Revert "evas/textblock - null check."
Hello, I think there is a misunderstanding here. One is describing what the patch does, the other want to know how to reproduce the bug that require this patch to be applied. In fact this has been a mistake we have been quite often in the past. Having commit message that basically duplicate the content of the code instead of explaining why are doing the change in the first place. Maybe we should formalize what we expect in a commit message so that this kind of misunderstanding doesn't happen (and also in 3 years from now, we will be able to figure out why we did do that). Cedric On Sun, Oct 6, 2013 at 2:08 PM, ChunEon Park wrote: > I don't agree that commit message bad. > > but fundamental problem is your maintained function. > > If you wanna blame to me, then please fix the function first. (if you really > think you are the textblock maintainer) > > > -Regards, Hermet- > > -Original Message- > From: "Tom Hacohen" > To: ; > Cc: > Sent: 2013-10-04 (금) 21:59:15 > Subject: Re: [E-devel] [EGIT] [core/efl] master 01/01: Revert "evas/textblock > - null check." > > On 04/10/13 13:09, ChunEon Park wrote: >> it shouldn't be in. maybe. >> >> but you made the function to return NULL. >> >> and then you want to know reason by other people? >> > > Maybe it should, maybe it shouldn't the point is, I don't know. You are > now trying to explain yourself in the ML, why not explain what you were > trying to fix in the commit message itself? > > I didn't do anything, you did this commit. I have no idea what you are > talking about, what NULL I was returning and what reasons you are > talking about. > > As Sachiel said: explain what you were trying to do in the commit > message so people can actually review and understand what you were > trying to do. > > As for this commit: please explain what you mean and why you added this > fix, but this is unrelated to the discussion at hand. The discussion is > about the bad commit message that made it impossible for me to review > your patch. > > -- > Tom. > > > -- > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Cedric BAIL -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
Yeah, you can delete the remote branch after merging to master. The trick here is that we don't send emails about commits in dev branches and we don't send emails about commits that were merged into master from a dev branch (that is, commits that have already existed in the repo at the time of the push). Pushing to a dev branch first will thus prevent the emails from being sent. -- Tom. On Sun, Oct 6, 2013 at 5:09 PM, Daniel Juyung Seo wrote: > But that will create a remote branch which is not needed for others. > Or I can delete the remote branch after merging to master. Is that ok? > > Daniel Juyung Seo (SeoZ) > > > On Sun, Oct 6, 2013 at 12:36 AM, Tom Hacohen wrote: > > > Well. There's a way to avoid that: If you push to a remote branch before > > merging, there will be no tsunami. A mail will only be sent to the merge > > commit. > > > > > > On Sat, Oct 5, 2013 at 4:05 PM, Daniel Juyung Seo > >wrote: > > > > > I thought the same as David Seikel :) > > > That's why the commit tsunami happened. > > > > > > Anyhow, it's same as before except we now allow merge commit for some > > > cases. > > > > > > Daniel Juyung Seo (SeoZ) > > > > > > On Sat, Oct 5, 2013 at 8:09 PM, Tom Hacohen wrote: > > > > > > > No. The point is not to squash them, but have one cover-letter commit > > > that > > > > holds them all. If you "git log --first-parent" you won't see all the > > > > commits, just the merge commit that describes the whole changeset. > > > > > > > > > > > > On Sat, Oct 5, 2013 at 10:36 AM, David Seikel > > wrote: > > > > > > > > > On Sat, 5 Oct 2013 17:58:17 +0900 Daniel Juyung Seo > > > > > wrote: > > > > > > > > > > > On Fri, Oct 4, 2013 at 11:48 PM, Tom Hacohen > > > > > > wrote: > > > > > > > > > > > > > On 04/10/13 15:40, Michael Blumenkrantz wrote: > > > > > > > > On Fri, 04 Oct 2013 15:18:46 +0100 > > > > > > > > Tom Hacohen wrote: > > > > > > > > > > > > > > > >> On 02/10/13 16:17, Tom Hacohen wrote: > > > > > > > >>> Hey guys, > > > > > > > >>> > > > > > > > >>> I would like to suggest a new work-flow. This work-flow > will > > > > > > > >>> not be mandatory, but just an allowed alternative to the > > > > > > > >>> current "commit to master" approach. > > > > > > > >>> > > > > > > > >>> At the moment we do not allow merges, at all. This was to > > > > > > > >>> prevent > > > > > > > people > > > > > > > >>> from littering the log with their inability to rebase (git > > pull > > > > > > > >>> --rebase) their local changes on top of the existing > commits. > > > > > > > >>> This will still remain the same. I'd like to suggest using > > > > > > > >>> merges to our > > > > > > > advantage. > > > > > > > >>> > > > > > > > >>> I suggest the following: > > > > > > > >>> For fixes, small features, and the like, do the same as you > > do > > > > > > > >>> now. Commit and push to master. > > > > > > > >>> > > > > > > > >>> For bigger features, rewrites, or any form of a few commits > > > > > > > >>> that are tied together by being part of the same set, do as > > > > > > > >>> follows (it's obviously simpler than that, I listed > > everything > > > > > > > >>> to over-simplify > > > > > > > things): > > > > > > > >>> 1. Create a branch (either local or remote) for your > change. > > > > > > > >>> 2. Work on that branch. > > > > > > > >>> 3. When ready, instead of pushing to master: > > > > > > > >>> 3. rebase over master (git fetch; git rebase > origin/master). > > > > > > > >>> 4. switch to master (git checkout master) > > > > > > > >>> 6. git merge --no-ff your-feature-branch-name > > > > > > > >>> 7. Describe your feature in the commit message. > > > > > > > >>> 8. push to master (git push or git push origin master). > > > > > > > >>> > > > > > > > >>> I've done a few example commits on > > > > > > > >>> > > > > https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ > > > > > > > >>> > > > > > > > >>> This work-flow lets us have linear history, while having > > > > > > > >>> feature-sets show as a single merge that can easily be > > > > > > > >>> reverted, provide a good description about a feature and > the > > > > > > > >>> commits that introduced it and I find generally easier for > > the > > > > > > > >>> eye. There are also technical advantages, for example, if > you > > > > > > > >>> run "git log --first-parent" you will only see the merge > > > > > > > >>> commits, cleaning the log from all the fluff involving a > > > > > > > >>> feature letting you just see the feature. Another advantage > > is > > > > > > > >>> that "git > > > > > > > bisect" > > > > > > > >>> will not go inside the merged branch unless the issue was > > > > > > > >>> introduced > > > > > > > there. > > > > > > > >>> > > > > > > > >>> Please feel free to inspect my repo, more specifically, the > > > log: > > > > > > > >>> > > > > > > > https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ > > > > > > > >>> > > > > > > > >>> To see how it looks. > > > > > > > >>> > > > > > > > >>> Important not
[EGIT] [e16/e16] master 02/02: Obsolete event handling tweak.
kwo pushed a commit to branch master.
http://git.enlightenment.org/e16/e16.git/commit/?id=f6ff19cef193ab9973fc0506c2da73ed3043dad7
commit f6ff19cef193ab9973fc0506c2da73ed3043dad7
Author: Kim Woelders
Date: Sun Oct 6 21:30:27 2013 +0200
Obsolete event handling tweak.
Avoid trouble around obsolete events and click grabs.
---
src/ewins.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/src/ewins.c b/src/ewins.c
index 6ce7bbb..a518aa3 100644
--- a/src/ewins.c
+++ b/src/ewins.c
@@ -2457,15 +2457,17 @@ EwinHandleEventsContainer(Win win __UNUSED__, XEvent *
ev, void *prm)
{
EWin *ewin = (EWin *) prm;
+ if (ev->type == ButtonPress)
+ {
+ FocusHandleClick(ewin, EwinGetClientConWin(ewin));
+ return;
+ }
+
if (!_EwinEventEwinCheck("cont", ev, ewin))
return;
switch (ev->type)
{
- case ButtonPress:
- FocusHandleClick(ewin, EwinGetContainerWin(ewin));
- break;
-
default:
if (EwinHandleContainerEvents(ewin, ev))
break;
@@ -2483,17 +2485,19 @@ EwinHandleEventsClient(Win win __UNUSED__, XEvent * ev,
void *prm)
{
EWin *ewin = (EWin *) prm;
+#if !USE_CONTAINER_WIN
+ if (ev->type == ButtonPress)
+ {
+ FocusHandleClick(ewin, EwinGetClientConWin(ewin));
+ return;
+ }
+#endif
+
if (!_EwinEventEwinCheck("cli", ev, ewin))
return;
switch (ev->type)
{
-#if !USE_CONTAINER_WIN
- case ButtonPress:
- FocusHandleClick(ewin, EwinGetClientConWin(ewin));
- break;
-#endif
-
case FocusIn:
case FocusOut:
if (ev->xfocus.detail == NotifyInferior)
--
[EGIT] [e16/e16] master 01/02: Obsolete event handling tweak.
kwo pushed a commit to branch master.
http://git.enlightenment.org/e16/e16.git/commit/?id=3f51b8c8719790654862b1fc0a92743366b994a5
commit 3f51b8c8719790654862b1fc0a92743366b994a5
Author: Kim Woelders
Date: Sun Oct 6 21:23:38 2013 +0200
Obsolete event handling tweak.
Reduce probability of trouble that may occur if event serial number
difference since last wraps.
---
src/ewins.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/ewins.c b/src/ewins.c
index 7ccb726..6ce7bbb 100644
--- a/src/ewins.c
+++ b/src/ewins.c
@@ -2313,7 +2313,10 @@ ActionsCheck(const char *which, EWin * ewin, XEvent * ev)
static EWin*
_EwinEventEwinCheck(const char *txt, XEvent * ev, EWin * ewin)
{
- if ((int)(ev->xany.serial - ewin->serial) < 0)
+ int ser_diff;
+
+ ser_diff = (int)(ev->xany.serial - ewin->serial);
+ if (ser_diff < 0 && ser_diff > -1000)
{
Eprintf("%s: %#lx: Ignore obsolete event %d\n", txt,
ev->xany.window, ev->type);
--
Re: [E-devel] Git, merges, and better work-flows
But that will create a remote branch which is not needed for others. Or I can delete the remote branch after merging to master. Is that ok? Daniel Juyung Seo (SeoZ) On Sun, Oct 6, 2013 at 12:36 AM, Tom Hacohen wrote: > Well. There's a way to avoid that: If you push to a remote branch before > merging, there will be no tsunami. A mail will only be sent to the merge > commit. > > > On Sat, Oct 5, 2013 at 4:05 PM, Daniel Juyung Seo >wrote: > > > I thought the same as David Seikel :) > > That's why the commit tsunami happened. > > > > Anyhow, it's same as before except we now allow merge commit for some > > cases. > > > > Daniel Juyung Seo (SeoZ) > > > > On Sat, Oct 5, 2013 at 8:09 PM, Tom Hacohen wrote: > > > > > No. The point is not to squash them, but have one cover-letter commit > > that > > > holds them all. If you "git log --first-parent" you won't see all the > > > commits, just the merge commit that describes the whole changeset. > > > > > > > > > On Sat, Oct 5, 2013 at 10:36 AM, David Seikel > wrote: > > > > > > > On Sat, 5 Oct 2013 17:58:17 +0900 Daniel Juyung Seo > > > > wrote: > > > > > > > > > On Fri, Oct 4, 2013 at 11:48 PM, Tom Hacohen > > > > > wrote: > > > > > > > > > > > On 04/10/13 15:40, Michael Blumenkrantz wrote: > > > > > > > On Fri, 04 Oct 2013 15:18:46 +0100 > > > > > > > Tom Hacohen wrote: > > > > > > > > > > > > > >> On 02/10/13 16:17, Tom Hacohen wrote: > > > > > > >>> Hey guys, > > > > > > >>> > > > > > > >>> I would like to suggest a new work-flow. This work-flow will > > > > > > >>> not be mandatory, but just an allowed alternative to the > > > > > > >>> current "commit to master" approach. > > > > > > >>> > > > > > > >>> At the moment we do not allow merges, at all. This was to > > > > > > >>> prevent > > > > > > people > > > > > > >>> from littering the log with their inability to rebase (git > pull > > > > > > >>> --rebase) their local changes on top of the existing commits. > > > > > > >>> This will still remain the same. I'd like to suggest using > > > > > > >>> merges to our > > > > > > advantage. > > > > > > >>> > > > > > > >>> I suggest the following: > > > > > > >>> For fixes, small features, and the like, do the same as you > do > > > > > > >>> now. Commit and push to master. > > > > > > >>> > > > > > > >>> For bigger features, rewrites, or any form of a few commits > > > > > > >>> that are tied together by being part of the same set, do as > > > > > > >>> follows (it's obviously simpler than that, I listed > everything > > > > > > >>> to over-simplify > > > > > > things): > > > > > > >>> 1. Create a branch (either local or remote) for your change. > > > > > > >>> 2. Work on that branch. > > > > > > >>> 3. When ready, instead of pushing to master: > > > > > > >>> 3. rebase over master (git fetch; git rebase origin/master). > > > > > > >>> 4. switch to master (git checkout master) > > > > > > >>> 6. git merge --no-ff your-feature-branch-name > > > > > > >>> 7. Describe your feature in the commit message. > > > > > > >>> 8. push to master (git push or git push origin master). > > > > > > >>> > > > > > > >>> I've done a few example commits on > > > > > > >>> > > > https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ > > > > > > >>> > > > > > > >>> This work-flow lets us have linear history, while having > > > > > > >>> feature-sets show as a single merge that can easily be > > > > > > >>> reverted, provide a good description about a feature and the > > > > > > >>> commits that introduced it and I find generally easier for > the > > > > > > >>> eye. There are also technical advantages, for example, if you > > > > > > >>> run "git log --first-parent" you will only see the merge > > > > > > >>> commits, cleaning the log from all the fluff involving a > > > > > > >>> feature letting you just see the feature. Another advantage > is > > > > > > >>> that "git > > > > > > bisect" > > > > > > >>> will not go inside the merged branch unless the issue was > > > > > > >>> introduced > > > > > > there. > > > > > > >>> > > > > > > >>> Please feel free to inspect my repo, more specifically, the > > log: > > > > > > >>> > > > > > https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ > > > > > > >>> > > > > > > >>> To see how it looks. > > > > > > >>> > > > > > > >>> Important note: commits on the merge branch should be treated > > > > > > >>> as if > > > > > > they > > > > > > >>> are on master, that is, don't use this as an excuse to make > > ugly > > > > > > commits > > > > > > >>> with bad commit messages. > > > > > > >>> > > > > > > >>> Again: I'm not trying to make it mandatory, just to allow > this > > > > > > >>> sort of merges. > > > > > > >>> > > > > > > >>> Please let me know what you think. > > > > > > >>> > > > > > > >>> -- > > > > > > >>> Tom. > > > > > > >>> > > > > > > >>> > > > > > > > > > > > > > > > > -- > > > > > > >>> October Webinars: Code for Performan
Re: [E-devel] [EGIT] [core/elementary] master 01/01: elementary/scroller - set the NULL to not access dangling pointer after deleting animator.
Oops. Sorry it's my bad.
Thanks for the fix.
Daniel Juyung Seo (SeoZ)
On Sun, Oct 6, 2013 at 11:36 PM, ChunEon Park wrote:
> hermet pushed a commit to branch master.
>
>
> http://git.enlightenment.org/core/elementary.git/commit/?id=e9ee16a88a80f3fe929f91494ae462b280fa861c
>
> commit e9ee16a88a80f3fe929f91494ae462b280fa861c
> Author: ChunEon Park
> Date: Sun Oct 6 23:35:51 2013 +0900
>
> elementary/scroller - set the NULL to not access dangling pointer
> after deleting animator.
> ---
> src/lib/elm_interface_scrollable.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/lib/elm_interface_scrollable.c
> b/src/lib/elm_interface_scrollable.c
> index cfa76e0..2cbb0c9 100644
> --- a/src/lib/elm_interface_scrollable.c
> +++ b/src/lib/elm_interface_scrollable.c
> @@ -1463,7 +1463,7 @@
> _elm_scroll_bounce_eval(Elm_Scrollable_Smart_Interface_Data *sid)
>{
> if (sid->bouncemex)
> {
> - if (sid->scrollto.x.animator)
> ecore_animator_del(sid->scrollto.x.animator);
> + ELM_SAFE_FREE(sid->scrollto.x.animator,
> ecore_animator_del);
>sid->down.bounce_x_animator =
> ecore_animator_add(_elm_scroll_bounce_x_animator,
> sid->obj);
>sid->down.anim_start2 = ecore_loop_time_get();
> @@ -1483,7 +1483,7 @@
> _elm_scroll_bounce_eval(Elm_Scrollable_Smart_Interface_Data *sid)
>{
> if (sid->bouncemey)
> {
> - if (sid->scrollto.y.animator)
> ecore_animator_del(sid->scrollto.y.animator);
> + ELM_SAFE_FREE(sid->scrollto.y.animator,
> ecore_animator_del);
>sid->down.bounce_y_animator =
> ecore_animator_add(_elm_scroll_bounce_y_animator,
> sid->obj);
>sid->down.anim_start3 = ecore_loop_time_get();
>
> --
>
>
>
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/elementary] master 01/01: elementary/scroller - set the NULL to not access dangling pointer after deleting animator.
hermet pushed a commit to branch master.
http://git.enlightenment.org/core/elementary.git/commit/?id=e9ee16a88a80f3fe929f91494ae462b280fa861c
commit e9ee16a88a80f3fe929f91494ae462b280fa861c
Author: ChunEon Park
Date: Sun Oct 6 23:35:51 2013 +0900
elementary/scroller - set the NULL to not access dangling pointer after
deleting animator.
---
src/lib/elm_interface_scrollable.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/lib/elm_interface_scrollable.c
b/src/lib/elm_interface_scrollable.c
index cfa76e0..2cbb0c9 100644
--- a/src/lib/elm_interface_scrollable.c
+++ b/src/lib/elm_interface_scrollable.c
@@ -1463,7 +1463,7 @@
_elm_scroll_bounce_eval(Elm_Scrollable_Smart_Interface_Data *sid)
{
if (sid->bouncemex)
{
- if (sid->scrollto.x.animator)
ecore_animator_del(sid->scrollto.x.animator);
+ ELM_SAFE_FREE(sid->scrollto.x.animator, ecore_animator_del);
sid->down.bounce_x_animator =
ecore_animator_add(_elm_scroll_bounce_x_animator,
sid->obj);
sid->down.anim_start2 = ecore_loop_time_get();
@@ -1483,7 +1483,7 @@
_elm_scroll_bounce_eval(Elm_Scrollable_Smart_Interface_Data *sid)
{
if (sid->bouncemey)
{
- if (sid->scrollto.y.animator)
ecore_animator_del(sid->scrollto.y.animator);
+ ELM_SAFE_FREE(sid->scrollto.y.animator, ecore_animator_del);
sid->down.bounce_y_animator =
ecore_animator_add(_elm_scroll_bounce_y_animator,
sid->obj);
sid->down.anim_start3 = ecore_loop_time_get();
--
Re: [E-devel] [EGIT] [core/efl] master 01/01: Revert "evas/textblock - null check."
I don't agree that commit message bad. but fundamental problem is your maintained function. If you wanna blame to me, then please fix the function first. (if you really think you are the textblock maintainer) -Regards, Hermet- -Original Message- From: "Tom Hacohen" To: ; Cc: Sent: 2013-10-04 (금) 21:59:15 Subject: Re: [E-devel] [EGIT] [core/efl] master 01/01: Revert "evas/textblock - null check." On 04/10/13 13:09, ChunEon Park wrote: > it shouldn't be in. maybe. > > but you made the function to return NULL. > > and then you want to know reason by other people? > Maybe it should, maybe it shouldn't the point is, I don't know. You are now trying to explain yourself in the ML, why not explain what you were trying to fix in the commit message itself? I didn't do anything, you did this commit. I have no idea what you are talking about, what NULL I was returning and what reasons you are talking about. As Sachiel said: explain what you were trying to do in the commit message so people can actually review and understand what you were trying to do. As for this commit: please explain what you mean and why you added this fix, but this is unrelated to the discussion at hand. The discussion is about the bad commit message that made it impossible for me to review your patch. -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Wayland and subsurfaces
On 10/06/13 06:11, Cedric BAIL wrote: > On Sat, Oct 5, 2013 at 12:05 AM, Rafael Antognolli > wrote: >> Example usage of what I have just committed (fixes and improvements >> for Evas_Video_Surface, and added Ecore_Wl_Subsurf) here: >> >> https://github.com/antognolli/buffer_object >> >> This is a helper, or a skeleton, for creating and setting up the image >> object that would be used with the buffers. It can be made more >> generic if necessary, thus allowing to use both Wayland buffers or X >> stuff. The code itself is inside buffer_object.c. Sample usage is >> inside main.c. > That's exactly the direction where I wanted to get that code. Really > nice patch, thanks. The next improvement I was looking for was to use > somehow the pixels buffer directly when using OpenGL (zero copy > scheme), by looking at your code I do think than in compositing mode > we are still doing a copy. Am i right ? > >> Anyway, this can be added somewhere in EFL, I just don't know exactly >> where would be the best place... ideas? > That is indeed a good question. I guess the first place to use this is > somewhere in Emotion's gstreamer backend. I would even prefer to see > that feature working with VLC backend, but I don't think there is a > way to make vlc output the pixels in a wayland surface. Not currently :( And I would not count on one anytime soon :( https://trac.videolan.org/vlc/ticket/7936 Although, if we had the pixels (I don't know the VLC code too well) then we should be able to slap those into a surface... dh > Also the > gstreamer backend is easier to integrate as it doesn't require to > communicate with another process to get the pixels (Not really a win > in my opinion, but in this case will make life easier). > > Also I have been starting to think that maybe we should have a simpler > layer than Emotion that does all this buffer management and his used > by Emotion. That's just a though right now. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: Revert "evas/textblock - null check."
/**
* @internal
* Returns the visible format at a specific location.
*
* @param n a format at the specific position.
* @return the format node at the specific position or NULL if not found.
*/
static Evas_Object_Textblock_Node_Format *
_evas_textblock_node_visible_at_pos_get(const Evas_Object_Textblock_Node_Format
*n)
{
}
I think the problem is not the commit and commit message.
But the function does
-Regards, Hermet-
-Original Message-
From: "Iván Briano"
To: "Enlightenment developer list";
Cc:
Sent: 2013-10-04 (금) 21:52:28
Subject: Re: [E-devel] [EGIT] [core/efl] master 01/01: Revert "evas/textblock -
null check."
On Fri, Oct 4, 2013 at 9:09 AM, ChunEon Park @naver.com> wrote:
> it shouldn't be in. maybe.
>
> but you made the function to return NULL.
>
> and then you want to know reason by other people?
The point is to properly explain in the commit message the reason for
the commit.
>
>
> -Regards, Hermet-
>
> -Original Message-
> From: "Tom Hacohen"@samsung.com>
> To: @lists.sourceforge.net>;
> Cc:
> Sent: 2013-10-04 (금) 19:59:02
> Subject: Re: [E-devel] [EGIT] [core/efl] master 01/01: Revert "evas/textblock
> - null check."
>
> On 03/10/13 19:02, ChunEon Park wrote:
>> If so,
>> why dot you leave the evas_textblock_cursor_format_is_visible_get() to
>> return NULL if you think it must verify the fnode?
>
> You missed the whole point of the revert. The point of the revert was my
> inability to review your patch, and thus I couldn't assure it should be
> kept in. Looking at it, it feels like it sholudn't be in, and without
> proper explanation, I couldn't have been convinced.
>
> Maybe it doesn't verify the node, I don't remember, but again, read up.
>
> --
> Tom.
>
>
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [apps/terminology] master 01/01: theme - sync stripe imagery with dark in e17/elm theme and remove the pulse
raster pushed a commit to branch master.
http://git.enlightenment.org/apps/terminology.git/commit/?id=0f615122e585edf872d189d5ab7f09297d8748b7
commit 0f615122e585edf872d189d5ab7f09297d8748b7
Author: Carsten Haitzler (Rasterman)
Date: Sun Oct 6 20:42:37 2013 +0900
theme - sync stripe imagery with dark in e17/elm theme and remove the pulse
---
data/themes/default.edc | 201 +--
data/themes/images/sl_stripe.png | Bin 322 -> 1024 bytes
2 files changed, 4 insertions(+), 197 deletions(-)
diff --git a/data/themes/default.edc b/data/themes/default.edc
index eb5c030..5900d67 100644
--- a/data/themes/default.edc
+++ b/data/themes/default.edc
@@ -1394,10 +1394,8 @@ collections {
// bottomfull:
// |##|
// |##|
-#define PATCOL 51 153 255 128
-#define PATCOL2 51 153 255 144
+#define PATCOL 255 255 255 25
#define OUTCOL 51 153 255 128
-#define OUTCOL2 51 153 255 255
group { name: "terminology/selection";
images {
@@ -1419,11 +1417,7 @@ collections {
color: PATCOL;
image.normal: "sl_stripe.png";
fill.size.relative: 0.0 0.0;
- fill.size.offset: 40 40;
-}
-description { state: "pulse" 0.0;
- inherit: "default" 0.0;
- color: PATCOL2;
+ fill.size.offset: 240 240;
}
}
part { name: "background_middle";
@@ -1433,11 +1427,7 @@ collections {
color: PATCOL;
image.normal: "sl_stripe.png";
fill.size.relative: 0.0 0.0;
- fill.size.offset: 40 40;
-}
-description { state: "pulse" 0.0;
- inherit: "default" 0.0;
- color: PATCOL2;
+ fill.size.offset: 240 240;
}
}
part { name: "background_bottom";
@@ -1447,11 +1437,7 @@ collections {
color: PATCOL;
image.normal: "sl_stripe.png";
fill.size.relative: 0.0 0.0;
- fill.size.offset: 40 40;
-}
-description { state: "pulse" 0.0;
- inherit: "default" 0.0;
- color: PATCOL2;
+ fill.size.offset: 240 240;
}
}
@@ -1564,10 +1550,6 @@ target: "0.clip"; target: "1.clip"; target: "2.clip";
target: "3.clip"; target:
image.border: 0 0 4 4;
fill.smooth: 0;
}
-description { state: "pulse" 0.0;
- inherit: "default" 0.0;
- color: OUTCOL2;
-}
}
part { name: "0.right";
mouse_events: 0;
@@ -1588,10 +1570,6 @@ target: "0.clip"; target: "1.clip"; target: "2.clip";
target: "3.clip"; target:
image.border: 0 0 4 4;
fill.smooth: 0;
}
-description { state: "pulse" 0.0;
- inherit: "default" 0.0;
- color: OUTCOL2;
-}
}
part { name: "0.top";
mouse_events: 0;
@@ -1611,10 +1589,6 @@ target: "0.clip"; target: "1.clip"; target: "2.clip";
target: "3.clip"; target:
image.normal: "sl_htop.png";
fill.smooth: 0;
}
-description { state: "pulse" 0.0;
- inherit: "default" 0.0;
- color: OUTCOL2;
-}
}
part { name: "0.bottom";
mouse_events: 0;
@@ -1634,10 +1608,6 @@ target: "0.clip"; target: "1.clip"; target: "2.clip";
target: "3.clip"; target:
image.normal: "sl_hbottom.png";
fill.smooth: 0;
}
-description { state: "pulse" 0.0;
- inherit: "default" 0.0;
- color: OUTCOL2;
-}
}
program { name: "oneline";
signal: "mode,oneline";
@@ -1668,10 +1638,6 @@ target: "0.clip"; target: "1.clip"; target: "2.clip";
target: "3.clip"; target:
image.border: 0 0 4 4;
fill.smooth: 0;
}
-description { state: "pulse" 0.0;
- inherit: "default" 0.0;
- color: OUTCOL2;
-}
}
part { name: "1.right";
mouse_events: 0;
@@ -1692,10 +1658,6 @@ target: "0.clip"; target: "1.clip"; target: "2.clip";
target: "3.clip"; target:
image.border: 0 0 4 4;
fill.smooth: 0;
}
-description { state: "pulse" 0.0;
- inherit: "default" 0.0;
- color: OUTCOL2;
-}
}
part { name: "1.top";
mouse_events: 0;
@@ -1715,10 +1677,6 @@ target: "0.clip"; target: "1.clip"; target: "2.clip";
target: "3.clip"; target:
image.normal: "sl_htop.png";
fill.smooth: 0;
}
-description { state: "p
