Re: [E-devel] [EGIT] [core/efl] master 01/01: Check for valid string before trying to write (potentially NULL) to the pipe.
On 09/07/13 01:56, Cedric BAIL wrote: > On Mon, Jul 8, 2013 at 10:39 PM, Chris Michael - Enlightenment Git > wrote: >> devilhorns pushed a commit to branch master. >> >> commit 6e49578cb779a26a8bebb61402facf99c1aa5341 >> Author: Chris Michael >> Date: Mon Jul 8 14:38:54 2013 +0100 >> >> Check for valid string before trying to write (potentially NULL) to >> the pipe. >> >> NB: Fixes Coverity CID1039398 >> >> Signed-off-by: Chris Michael >> --- >> src/modules/emotion/generic/emotion_generic.c | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/src/modules/emotion/generic/emotion_generic.c >> b/src/modules/emotion/generic/emotion_generic.c >> index 5706511..1819f53 100644 >> --- a/src/modules/emotion/generic/emotion_generic.c >> +++ b/src/modules/emotion/generic/emotion_generic.c >> @@ -108,7 +108,9 @@ _player_send_str(Emotion_Generic_Video *ev, const char >> *str, Eina_Bool stringsha >>len = str ? eina_stringshare_strlen(str) + 1 : 0; >> else >>len = str ? strlen(str) + 1 : 0; >> - ecore_pipe_write(ev->fd_write, str, len); >> + >> + if (str) >> + ecore_pipe_write(ev->fd_write, str, len); >> } > Not sure it was a real problem as len would have been zero in that case. > -- > Cedric BAIL I cannot argue with your logic ;) I would however say this ... Even tho it may not have been a "real" problem, does this commit Hurt anything ? I would say No ;) dh -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Elementary scroll bad behavior
On Tue, Jul 9, 2013 at 12:13 PM, Cedric BAIL wrote: > On Tue, Jul 9, 2013 at 11:21 AM, Daniel Juyung Seo > wrote: > > This was caused by thumb scroll flick distance tolerance adoption from > > Jaehwan. > > I noticed this and was about to announce how to fix but stuck with > another > > bug in elementary_config + slider. > > > > Anyhow, if this happens just run elementary_config and go to scrolling, > > change "Thumb scroll flick distance tolerance" to 1000 or something you > > like. > > And close elementary_config. > > It should work. > > Maybe would be good to detect that wasn't properly configured before > and put some default sane value. > Yes I already added that feature two months ago. And now it's applied with the new scroller configuration. http://git.enlightenment.org/core/elementary.git/commit/?id=ddb2feb3e667b837743321652e5ce80cc7397714 There should be no issue. Thanks for the remind. Daniel Juyung Seo (SeoZ) > -- > Cedric BAIL > > > -- > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] calculate fps in edc efl
On Tue, 18 Jun 2013 09:26:02 +0530 "378anurag ." said: > Hi , > I have created three swallow panel in edc which i am rotating > circular on button click. > I need to calculate the performance i.e. fps. > is their any way to calculate the fps in edc edge or in efl at evas level. you can use post-render callbacks in evas... and just time the time between each post render callback.. ecore-evas offers this in the cmdline by default: $ export ECORE_EVAS_FPS_DEBUG=1 $ elementary_test -to Animation FRAME: 33, FPS: 63.4, RTIME 3% FRAME: 63, FPS: 60.0, RTIME 1% FRAME: 94, FPS: 60.0, RTIME 1% FRAME: 125, FPS: 60.0, RTIME 1% FRAME: 155, FPS: 60.0, RTIME 1% FRAME: 185, FPS: 60.0, RTIME 1% ... etc. :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Terminology miniview feature
On Sun, 23 Jun 2013 03:21:38 +0300 Galatsanos Panagiotis
said:
missing scrolio.h in patch! :(
> Ignore the previous patch, use this attachment instead.
>
>
> On Sun, Jun 23, 2013 at 2:44 AM, Galatsanos Panagiotis <
> galatsan...@gmail.com> wrote:
>
> > After spending some time on the miniview feature and with the help of
> > raster I finally reached the point where it is somehow usable.
> >
> > I have some issues where i need some guidance/help/feedback.
> > First, I want to bring miniview image below controls menu but i don't know
> > how. Currently when miniview is enabled and we have some history lines
> > drawn, when you press right click the controls menu is below miniview but
> > we don't want this...
> >
> > My second issue is that i want to use an animation when miniview
> > appears/dissapears. Actually what I want for default behaviour is this:
> > When the user enables miniview it'll slide in from the right and it will
> > show up just for couple of seconds (lets say 5), then it will slide back
> > and only one small part of the miniview will be visible only to indicate to
> > the user that it's enabled and when the user mouses over it will re-slide
> > in...
> >
> > Also i'm having an issue when resizing the window, some "garbage" pixels
> > are drawn inside the miniview image and I can't find where are coming from.
> > If someone has a clue it'll be very helpfull! :D
> >
> > Please try my patch and tell me what you think
> > Cheers, Panos.
> >
> > From 5c334290e9aa1d6aa2a02ae6bde8ff7a3d6dece6 Mon Sep 17 00:00:00 2001
> > From: Godfath3r
> > Date: Sun, 23 Jun 2013 03:07:27 +0300
> > Subject: [PATCH 1/1] add miniview feature to terminology. Pressing
> > ctrl+shift+f toggles miniview on the side of each
> > terminal/split/tab
> >
> > ---
> > data/themes/default.edc | 24 +++
> > src/bin/Makefile.am | 1 +
> > src/bin/config.c| 5 +
> > src/bin/config.h| 1 +
> > src/bin/main.c | 61 +++-
> > src/bin/scrolio.c | 397
> >
> > src/bin/termio.c| 101 +++-
> > src/bin/termio.h| 3 +
> > 8 files changed, 582 insertions(+), 11 deletions(-)
> > create mode 100644 src/bin/scrolio.c
> > create mode 100644 src/bin/scrolio.h
> >
> > diff --git a/data/themes/default.edc b/data/themes/default.edc
> > index 42e3f2a..dfeea2d 100644
> > --- a/data/themes/default.edc
> > +++ b/data/themes/default.edc
> > @@ -3597,4 +3597,28 @@ target: "4.bottom"
> > }
> >}
> > }
> > +
> > + group { name: "terminology/miniview";
> > + parts {
> > + part { name: "miniview"; type: SWALLOW;
> > +mouse_events: 0;
> > +description { state: "default" 0.0;
> > + color: 25 50 30 100;
> > + rel1.relative: 0.85 0.0;
> > +}
> > + }
> > + part { name: "miniview_screen"; type: RECT;
> > +mouse_events: 1;
> > +dragable {
> > + confine: "miniview";
> > + x: 0 0 0;
> > + y: 1 1 0;
> > +}
> > +description { state: "default" 0.0;
> > + color: 255 255 255 30;
> > + fixed:1 1;
> > +}
> > + }
> > + }
> > + }
> > }
> > diff --git a/src/bin/Makefile.am b/src/bin/Makefile.am
> > index e95dae7..3be4322 100644
> > --- a/src/bin/Makefile.am
> > +++ b/src/bin/Makefile.am
> > @@ -27,6 +27,7 @@ options_video.c options_video.h \
> > options_theme.c options_theme.h \
> > options_wallpaper.c options_wallpaper.h \
> > sel.c sel.h \
> > +scrolio.c scrolio.h \
> > termio.c termio.h \
> > termcmd.c termcmd.h \
> > termiolink.c termiolink.h \
> > diff --git a/src/bin/config.c b/src/bin/config.c
> > index eafa3da..f03e041 100644
> > --- a/src/bin/config.c
> > +++ b/src/bin/config.c
> > @@ -89,6 +89,8 @@ config_init(void)
> > (edd_base, Config, "cg_width", cg_width, EET_T_INT);
> > EET_DATA_DESCRIPTOR_ADD_BASIC
> > (edd_base, Config, "cg_height", cg_height, EET_T_INT);
> > + EET_DATA_DESCRIPTOR_ADD_BASIC
> > + (edd_base, Config, "miniview", miniview, EET_T_UCHAR);
> > }
> >
> > void
> > @@ -171,6 +173,7 @@ config_sync(const Config *config_src, Config *config)
> > config->custom_geometry = config_src->custom_geometry;
> > config->cg_width = config_src->cg_width;
> > config->cg_height = config_src->cg_height;
> > + config->miniview = config_src->miniview;
> > }
> >
> > Config *
> > @@ -426,6 +429,7 @@ config_load(const char *key)
> > config->custom_geometry = EINA_FALSE;
> > config->cg_width = 80;
> > config->cg_height = 24;
> > + config->miniview = EINA_FALSE;
> >}
> > }
> >
> > @@ -474,6 +478,7 @@ config_fork(Config *config)
> > CPY(custom_geometry);
> > CPY(cg_width);
> > CPY(cg_height);
> > + CPY(miniview);
> >
> > CPY(temporary);
> > SCPY(config_
Re: [E-devel] Eo: potential improvements
On Mon, 08 Jul 2013 18:00:15 +0100 Tom Hacohen said: > Hey guys, > > The hero Jeremy Zurcher has been playing around and looking for ways to > improve Eo and address all the issues that have been raised by everyone. > We revisited some old ideas, tried some new ideas and changed our > compromises and preferences to better suit our needs (followed by the > extensive trial period). We think we made things better and we'd like to > hear your thoughts and suggestions. > > The code resides in devs/tasn/eo2. The differences are not major oh.. in the efl BRANCH... not the devs/tasn/eo2 git repo! i was looking there. > usage-wise (i.e eo_do), but are major internally and class-creation-wise. > There's an example of the usage of the new API in the eo2test directory. > The existing code-base hasn't been changed to use the new API, so > there's not a lot to review. > Eo2 is not complete, we'd like to hear your thoughts before finishing > things. > > Major changes: > 1. No more va_args, good ol' normal functions instead. > 2. Functions are resolved in eo and then called directly, creating a > "flatter" backtrace. > 3. We can have return values (to some extent). > 4. Less boiler-plate. > 5. Looks like we'll be able to get rid of some code thanks to this change. > 6. Possibly (probably) faster on platforms that pass parameters in > registers. > 7. Easier to do breakpoint on a specific eo_do call, instead of an > implementation. > > What we'd still like to achieve: > 1. Being able to drop the IDs in favour for more "friendly" IDs. It'd be > best to find a way to use the function pointers (for example) as the > IDs, but the problem is, that because function pointers are more > "unknown" we can do less optimisations on them which we'd like to avoid. > 2. Reduce more boiler-plate. > > Haven't been implemented yet: eo_do_super (among many other things). > > Additional comments: > EO_FUNC - this one creates a function that resolves and returns the > appropriate function. The functions created using this macro should be > used instead of the current eo macros. This one can potentially be improved. > eo2_do_start/end are just the entry/exit hooks of eo2_do (ref/unref and > possibly other stuff in the future). > > Looking forward to hearing what you have to say. > > -- > Tom. > > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Elementary scroll bad behavior
On Tue, Jul 9, 2013 at 11:21 AM, Daniel Juyung Seo wrote: > This was caused by thumb scroll flick distance tolerance adoption from > Jaehwan. > I noticed this and was about to announce how to fix but stuck with another > bug in elementary_config + slider. > > Anyhow, if this happens just run elementary_config and go to scrolling, > change "Thumb scroll flick distance tolerance" to 1000 or something you > like. > And close elementary_config. > It should work. Maybe would be good to detect that wasn't properly configured before and put some default sane value. -- Cedric BAIL -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo: potential improvements
Hello, On Tue, Jul 9, 2013 at 2:00 AM, Tom Hacohen wrote: > The hero Jeremy Zurcher has been playing around and looking for ways to > improve Eo and address all the issues that have been raised by everyone. > We revisited some old ideas, tried some new ideas and changed our > compromises and preferences to better suit our needs (followed by the > extensive trial period). We think we made things better and we'd like to > hear your thoughts and suggestions. > > The code resides in devs/tasn/eo2. The differences are not major > usage-wise (i.e eo_do), but are major internally and class-creation-wise. > There's an example of the usage of the new API in the eo2test directory. > The existing code-base hasn't been changed to use the new API, so > there's not a lot to review. > Eo2 is not complete, we'd like to hear your thoughts before finishing > things. > > Major changes: > 1. No more va_args, good ol' normal functions instead. > 2. Functions are resolved in eo and then called directly, creating a > "flatter" backtrace. > 3. We can have return values (to some extent). > 4. Less boiler-plate. > 5. Looks like we'll be able to get rid of some code thanks to this change. > 6. Possibly (probably) faster on platforms that pass parameters in > registers. > 7. Easier to do breakpoint on a specific eo_do call, instead of an > implementation. Sounds like valid point. > What we'd still like to achieve: > 1. Being able to drop the IDs in favour for more "friendly" IDs. It'd be > best to find a way to use the function pointers (for example) as the > IDs, but the problem is, that because function pointers are more > "unknown" we can do less optimisations on them which we'd like to avoid. > 2. Reduce more boiler-plate. > Haven't been implemented yet: eo_do_super (among many other things). There is more FIXME lurking around also in eo.c in your branch. > Additional comments: > EO_FUNC - this one creates a function that resolves and returns the > appropriate function. The functions created using this macro should be > used instead of the current eo macros. This one can potentially be improved. > eo2_do_start/end are just the entry/exit hooks of eo2_do (ref/unref and > possibly other stuff in the future). I have some issue with EO_FUNC. The main one being that I really can't get what the parameter of the created function are. Reading a header full of those will be completely useless to me ! The readability of that macro should really be improved. Also the eo2_do macro lead to weird eo_o parameter for all function call. This seems like a duplication and source for potential error. The second problem I see is that we are going to push a lot of pressure on the compiler with all this functions. Every EO_FUNC will be a static inline function, there is going to be a massive number of them in all our headers, slowing down compilation quite a lot. On a debugging and tracing ability, we do loose some ability there. There is no easy way to hook before and after the function call at this stage. This could be useful for many tools. Like Daniel's espion, that does something like strace but to an efl application. Or my starting attempt to do a performance analysis by knowing from which klass the function come from and where we do spend time. >From an optimization perspective, it would be good to mark eo_func_get as being 'pure' so it will eliminate multiple call if they are on the same object. Also did you do any benchmark comparing the previous use of eo_do with your new approach ? Right now using Eo doesn't slow us down, I would be interested to see a comparison of the same example (CPU, library size and used memory). > Looking forward to hearing what you have to say. Eo is one of the biggest change we did for 1.8. At this stage it is optimized to a point where we don't feel the cost compared to 1.7. It may be even faster in some work load and use less memory. Any major change like this is going to have an impact on any release for 1.8 (We are already 2 months late and will likely be 3, so what is it to add 2 more months delay). A major question is how fast can you roll your change in EFL ? That lead to an equivalent question, how many people have yet reviewed your proposal and are in favor of the change or have idea to improve it. I may want to put some pressure on that side, as I am really upset by our current delay on 1.8 and I really want to ear more than one voice in favor of another huge delay. Cheers, -- Cedric BAIL -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourcefo
Re: [E-devel] Eo: potential improvements
On Mon, 08 Jul 2013 18:00:15 +0100 Tom Hacohen said: > Hey guys, > > The hero Jeremy Zurcher has been playing around and looking for ways to > improve Eo and address all the issues that have been raised by everyone. > We revisited some old ideas, tried some new ideas and changed our > compromises and preferences to better suit our needs (followed by the > extensive trial period). We think we made things better and we'd like to > hear your thoughts and suggestions. > > The code resides in devs/tasn/eo2. The differences are not major > usage-wise (i.e eo_do), but are major internally and class-creation-wise. > There's an example of the usage of the new API in the eo2test directory. > The existing code-base hasn't been changed to use the new API, so > there's not a lot to review. > Eo2 is not complete, we'd like to hear your thoughts before finishing > things. > > Major changes: > 1. No more va_args, good ol' normal functions instead. good and bad. good as varags is a bit unwieldy. bad as in more symbols and either more function calls inlined in app code OR more code in general inlined (with macros or inline funcs). end result? unknown until we try. also another bad... work to port the existing eo code over. without full details, amount of work unknown. (missing git tree). > 2. Functions are resolved in eo and then called directly, creating a > "flatter" backtrace. > 3. We can have return values (to some extent). > 4. Less boiler-plate. > 5. Looks like we'll be able to get rid of some code thanks to this change. > 6. Possibly (probably) faster on platforms that pass parameters in > registers. hmm unlikely as now its: 1 func to begin 2 func to end 2 func call s per method as opposed to 1 func for begin+end, 1 func per method. i done see eo2 in git, so i can only comment on the point here, not the code. (if the lookup is a macro to get the func ptr, then call it directly, then sure, 2 fn call per method). another downside to it all being macros.. code size goes up, this instruction cache coherency goes down... :/ > 7. Easier to do breakpoint on a specific eo_do call, instead of an > implementation. > > What we'd still like to achieve: > 1. Being able to drop the IDs in favour for more "friendly" IDs. It'd be > best to find a way to use the function pointers (for example) as the > IDs, but the problem is, that because function pointers are more > "unknown" we can do less optimisations on them which we'd like to avoid. > 2. Reduce more boiler-plate. > > Haven't been implemented yet: eo_do_super (among many other things). > > Additional comments: > EO_FUNC - this one creates a function that resolves and returns the > appropriate function. The functions created using this macro should be > used instead of the current eo macros. This one can potentially be improved. > eo2_do_start/end are just the entry/exit hooks of eo2_do (ref/unref and > possibly other stuff in the future). > > Looking forward to hearing what you have to say. no tree. no git. :) > -- > Tom. > > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Elementary scroll bad behavior
This was caused by thumb scroll flick distance tolerance adoption from Jaehwan. I noticed this and was about to announce how to fix but stuck with another bug in elementary_config + slider. Anyhow, if this happens just run elementary_config and go to scrolling, change "Thumb scroll flick distance tolerance" to 1000 or something you like. And close elementary_config. It should work. Sorry for the inconvenience. Thanks. Daniel Juyung Seo (SeoZ) On Tue, Jul 9, 2013 at 3:45 AM, Rafael Antognolli wrote: > On Mon, Jul 8, 2013 at 2:45 PM, Iván Briano wrote: > > On Mon, Jul 8, 2013 at 2:38 PM, Rafael Antognolli > wrote: > >> Guys, anyone has noticed this? > >> > >> At least with mobile profile on desktop, if I try to scroll the > >> genlist inside elementary_test, it goes to the end and I can't go back > >> to the beginning anymore. Just try it and it should be obvious that > >> there's something wrong. > >> > > > > I saw that, opened elementary_config and chose the Mobile profile again > > (I was already using it, in theory), and it started working fine again. > > Yep, just worked, thanks. > > >> Not sure if there's a ticket for this yet, but if there's no ticket > >> I'll just create a new one. > >> > >> Regards, > >> -- > >> Rafael Antognolli > >> > >> > -- > >> This SF.net email is sponsored by Windows: > >> > >> Build for Windows Store. > >> > >> http://p.sf.net/sfu/windows-dev2dev > >> ___ > >> enlightenment-devel mailing list > >> enlightenment-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > > This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > -- > Rafael Antognolli > > > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&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: efreet: Low priority for cache rebuild
On Tue, Jul 9, 2013 at 3:38 AM, Sebastian Dransfeld wrote: > Den Jul 8, 2013 kl. 17:03 skrev Stefan Schmidt : >> On 06/20/2013 12:54 PM, Sebastian Dransfeld - Enlightenment Git wrote: >>> englebass pushed a commit to branch master. >>> >>> commit 58fc3a8f32d6fe71910ee0479afc3c8478c12540 >>> Author: Sebastian Dransfeld >>> Date: Thu Jun 20 13:53:54 2013 +0200 >>> >>> efreet: Low priority for cache rebuild >> >> We finally are back on track trying to get a mingw (cross compile for >> windows) build working with jenkins. This is the first error I get when >> trying to come through the efl build now. >> >> resources.h is not available on windows systems it seems. (Not using it >> at all just trying to keep it working for people that do :)) >> >> Was the original ecore_exe_run_priority_* better in this regard? >> > > Don't think so. This isn't very important, so just ifdef it. What was the problem with ecore_exe ? Is there a bug in it ? Just wondering as I would prefer to have it fixed in Ecore_Exe, if there is a problem there. -- Cedric BAIL -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&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: Check for valid string before trying to write (potentially NULL) to the pipe.
On Mon, Jul 8, 2013 at 10:39 PM, Chris Michael - Enlightenment Git wrote: > devilhorns pushed a commit to branch master. > > commit 6e49578cb779a26a8bebb61402facf99c1aa5341 > Author: Chris Michael > Date: Mon Jul 8 14:38:54 2013 +0100 > > Check for valid string before trying to write (potentially NULL) to > the pipe. > > NB: Fixes Coverity CID1039398 > > Signed-off-by: Chris Michael > --- > src/modules/emotion/generic/emotion_generic.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/src/modules/emotion/generic/emotion_generic.c > b/src/modules/emotion/generic/emotion_generic.c > index 5706511..1819f53 100644 > --- a/src/modules/emotion/generic/emotion_generic.c > +++ b/src/modules/emotion/generic/emotion_generic.c > @@ -108,7 +108,9 @@ _player_send_str(Emotion_Generic_Video *ev, const char > *str, Eina_Bool stringsha > len = str ? eina_stringshare_strlen(str) + 1 : 0; > else > len = str ? strlen(str) + 1 : 0; > - ecore_pipe_write(ev->fd_write, str, len); > + > + if (str) > + ecore_pipe_write(ev->fd_write, str, len); > } Not sure it was a real problem as len would have been zero in that case. -- Cedric BAIL -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo: potential improvements
On Mon, Jul 8, 2013 at 4:58 PM, Gustavo Sverzut Barbieri wrote: > forgot to git-daemon-export-ok? > http://git.enlightenment.org/devs/tasn/eo2.git = no repositories found > You can find it on the core efl repository in devs/tasn/eo2 branch. > > On Mon, Jul 8, 2013 at 2:00 PM, Tom Hacohen wrote: > >> Hey guys, >> >> The hero Jeremy Zurcher has been playing around and looking for ways to >> improve Eo and address all the issues that have been raised by everyone. >> We revisited some old ideas, tried some new ideas and changed our >> compromises and preferences to better suit our needs (followed by the >> extensive trial period). We think we made things better and we'd like to >> hear your thoughts and suggestions. >> >> The code resides in devs/tasn/eo2. The differences are not major >> usage-wise (i.e eo_do), but are major internally and class-creation-wise. >> There's an example of the usage of the new API in the eo2test directory. >> The existing code-base hasn't been changed to use the new API, so >> there's not a lot to review. >> Eo2 is not complete, we'd like to hear your thoughts before finishing >> things. >> >> Major changes: >> 1. No more va_args, good ol' normal functions instead. >> 2. Functions are resolved in eo and then called directly, creating a >> "flatter" backtrace. >> 3. We can have return values (to some extent). >> 4. Less boiler-plate. >> 5. Looks like we'll be able to get rid of some code thanks to this change. >> 6. Possibly (probably) faster on platforms that pass parameters in >> registers. >> 7. Easier to do breakpoint on a specific eo_do call, instead of an >> implementation. >> >> What we'd still like to achieve: >> 1. Being able to drop the IDs in favour for more "friendly" IDs. It'd be >> best to find a way to use the function pointers (for example) as the >> IDs, but the problem is, that because function pointers are more >> "unknown" we can do less optimisations on them which we'd like to avoid. >> 2. Reduce more boiler-plate. >> >> Haven't been implemented yet: eo_do_super (among many other things). >> >> Additional comments: >> EO_FUNC - this one creates a function that resolves and returns the >> appropriate function. The functions created using this macro should be >> used instead of the current eo macros. This one can potentially be >> improved. >> eo2_do_start/end are just the entry/exit hooks of eo2_do (ref/unref and >> possibly other stuff in the future). >> >> Looking forward to hearing what you have to say. >> >> -- >> Tom. >> >> >> -- >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-dev2dev >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Eduardo de Barros Lima ◤✠◢ ebl...@gmail.com -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo: potential improvements
forgot to git-daemon-export-ok? http://git.enlightenment.org/devs/tasn/eo2.git = no repositories found On Mon, Jul 8, 2013 at 2:00 PM, Tom Hacohen wrote: > Hey guys, > > The hero Jeremy Zurcher has been playing around and looking for ways to > improve Eo and address all the issues that have been raised by everyone. > We revisited some old ideas, tried some new ideas and changed our > compromises and preferences to better suit our needs (followed by the > extensive trial period). We think we made things better and we'd like to > hear your thoughts and suggestions. > > The code resides in devs/tasn/eo2. The differences are not major > usage-wise (i.e eo_do), but are major internally and class-creation-wise. > There's an example of the usage of the new API in the eo2test directory. > The existing code-base hasn't been changed to use the new API, so > there's not a lot to review. > Eo2 is not complete, we'd like to hear your thoughts before finishing > things. > > Major changes: > 1. No more va_args, good ol' normal functions instead. > 2. Functions are resolved in eo and then called directly, creating a > "flatter" backtrace. > 3. We can have return values (to some extent). > 4. Less boiler-plate. > 5. Looks like we'll be able to get rid of some code thanks to this change. > 6. Possibly (probably) faster on platforms that pass parameters in > registers. > 7. Easier to do breakpoint on a specific eo_do call, instead of an > implementation. > > What we'd still like to achieve: > 1. Being able to drop the IDs in favour for more "friendly" IDs. It'd be > best to find a way to use the function pointers (for example) as the > IDs, but the problem is, that because function pointers are more > "unknown" we can do less optimisations on them which we'd like to avoid. > 2. Reduce more boiler-plate. > > Haven't been implemented yet: eo_do_super (among many other things). > > Additional comments: > EO_FUNC - this one creates a function that resolves and returns the > appropriate function. The functions created using this macro should be > used instead of the current eo macros. This one can potentially be > improved. > eo2_do_start/end are just the entry/exit hooks of eo2_do (ref/unref and > possibly other stuff in the future). > > Looking forward to hearing what you have to say. > > -- > Tom. > > > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Elementary scroll bad behavior
On Mon, Jul 8, 2013 at 2:45 PM, Iván Briano wrote: > On Mon, Jul 8, 2013 at 2:38 PM, Rafael Antognolli > wrote: >> Guys, anyone has noticed this? >> >> At least with mobile profile on desktop, if I try to scroll the >> genlist inside elementary_test, it goes to the end and I can't go back >> to the beginning anymore. Just try it and it should be obvious that >> there's something wrong. >> > > I saw that, opened elementary_config and chose the Mobile profile again > (I was already using it, in theory), and it started working fine again. Yep, just worked, thanks. >> Not sure if there's a ticket for this yet, but if there's no ticket >> I'll just create a new one. >> >> Regards, >> -- >> Rafael Antognolli >> >> -- >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-dev2dev >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Rafael Antognolli -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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: efreet: Low priority for cache rebuild
Den Jul 8, 2013 kl. 17:03 skrev Stefan Schmidt :
> Hello.
>
> On 06/20/2013 12:54 PM, Sebastian Dransfeld - Enlightenment Git wrote:
>> englebass pushed a commit to branch master.
>>
>> commit 58fc3a8f32d6fe71910ee0479afc3c8478c12540
>> Author: Sebastian Dransfeld
>> Date: Thu Jun 20 13:53:54 2013 +0200
>>
>> efreet: Low priority for cache rebuild
>
> We finally are back on track trying to get a mingw (cross compile for
> windows) build working with jenkins. This is the first error I get when
> trying to come through the efl build now.
>
> resources.h is not available on windows systems it seems. (Not using it
> at all just trying to keep it working for people that do :))
>
> Was the original ecore_exe_run_priority_* better in this regard?
>
Don't think so. This isn't very important, so just ifdef it.
Sebastian
> regards
> Stefan Schmidt
>
>> ---
>> src/bin/efreet/efreet_desktop_cache_create.c | 3 +++
>> src/bin/efreet/efreet_icon_cache_create.c| 3 +++
>> src/bin/efreet/efreetd.c | 4
>> src/bin/efreet/efreetd_cache.c | 9 -
>> 4 files changed, 10 insertions(+), 9 deletions(-)
>>
>> diff --git a/src/bin/efreet/efreet_desktop_cache_create.c
>> b/src/bin/efreet/efreet_desktop_cache_create.c
>> index db3118c..17f41e3 100644
>> --- a/src/bin/efreet/efreet_desktop_cache_create.c
>> +++ b/src/bin/efreet/efreet_desktop_cache_create.c
>> @@ -5,6 +5,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>>
>> #include
>> #include
>> @@ -250,6 +252,7 @@ main(int argc, char **argv)
>> }
>> extra_dirs = eina_list_sort(extra_dirs, -1, EINA_COMPARE_CB(strcmp));
>>
>> +setpriority(PRIO_PROCESS, 0, 19);
>> /* init external subsystems */
>> if (!eet_init()) goto eet_error;
>> if (!ecore_init()) goto ecore_error;
>> diff --git a/src/bin/efreet/efreet_icon_cache_create.c
>> b/src/bin/efreet/efreet_icon_cache_create.c
>> index a4f774c..7473280 100644
>> --- a/src/bin/efreet/efreet_icon_cache_create.c
>> +++ b/src/bin/efreet/efreet_icon_cache_create.c
>> @@ -6,6 +6,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>>
>> #include
>> #include
>> @@ -768,6 +770,7 @@ main(int argc, char **argv)
>> flush = EINA_TRUE;
>> }
>>
>> +setpriority(PRIO_PROCESS, 0, 19);
>> if (!eet_init()) return -1;
>> if (!ecore_init()) return -1;
>>
>> diff --git a/src/bin/efreet/efreetd.c b/src/bin/efreet/efreetd.c
>> index 97b5162..d3f6d8c 100644
>> --- a/src/bin/efreet/efreetd.c
>> +++ b/src/bin/efreet/efreetd.c
>> @@ -2,6 +2,9 @@
>> # include
>> #endif
>>
>> +#include
>> +#include
>> +
>> #include
>> #include
>>
>> @@ -34,6 +37,7 @@ main(int argc, char *argv[])
>> if (!dbus_init()) goto dbus_error;
>> if (!cache_init()) goto cache_error;
>>
>> + setpriority(PRIO_PROCESS, 0, 19);
>> ecore_main_loop_begin();
>>
>> cache_shutdown();
>> diff --git a/src/bin/efreet/efreetd_cache.c
>> b/src/bin/efreet/efreetd_cache.c
>> index 4d7fd9d..c286b13 100644
>> --- a/src/bin/efreet/efreetd_cache.c
>> +++ b/src/bin/efreet/efreetd_cache.c
>> @@ -42,7 +42,6 @@ static Eina_Bool
>> icon_cache_update_cache_cb(void *data EINA_UNUSED)
>> {
>> char file[PATH_MAX];
>> - int prio;
>>
>> icon_cache_timer = NULL;
>>
>> @@ -55,9 +54,6 @@ icon_cache_update_cache_cb(void *data EINA_UNUSED)
>> if ((!icon_flush) && (!icon_exts)) return ECORE_CALLBACK_CANCEL;
>>
>> /* TODO: Queue if already running */
>> - prio = ecore_exe_run_priority_get();
>> - ecore_exe_run_priority_set(19);
>> -
>> snprintf(file, sizeof(file),
>> "%s/efreet/" MODULE_ARCH "/efreet_icon_cache_create",
>> eina_prefix_lib_get(pfx));
>> @@ -90,7 +86,6 @@ icon_cache_update_cache_cb(void *data EINA_UNUSED)
>> icon_flush = EINA_FALSE;
>> icon_cache_exe =
>>ecore_exe_pipe_run(file,
>> ECORE_EXE_PIPE_READ|ECORE_EXE_PIPE_READ_LINE_BUFFERED, NULL);
>> - ecore_exe_run_priority_set(prio);
>>
>> return ECORE_CALLBACK_CANCEL;
>> }
>> @@ -109,7 +104,6 @@ static Eina_Bool
>> desktop_cache_update_cache_cb(void *data EINA_UNUSED)
>> {
>> char file[PATH_MAX];
>> - int prio;
>>
>> desktop_cache_timer = NULL;
>>
>> @@ -119,8 +113,6 @@ desktop_cache_update_cache_cb(void *data EINA_UNUSED)
>> return ECORE_CALLBACK_CANCEL;
>> }
>> desktop_queue = EINA_FALSE;
>> - prio = ecore_exe_run_priority_get();
>> - ecore_exe_run_priority_set(19);
>>
>> snprintf(file, sizeof(file),
>> "%s/efreet/" MODULE_ARCH "/efreet_desktop_cache_create",
>> @@ -140,7 +132,6 @@ desktop_cache_update_cache_cb(void *data EINA_UNUSED)
>> INF("Run desktop cache creation: %s", file);
>> desktop_cache_exe =
>>ecore_exe_pipe_run(file,
>> ECORE_EXE_PIPE_READ|ECORE_EXE_PIPE_READ_LINE_BUFFERED, NULL);
>> - ecore_exe_run_priority_set(prio);
>>
>> return ECORE_CALLBACK_CANCEL;
>> }
>
>
>
Re: [E-devel] Elementary scroll bad behavior
On Mon, Jul 8, 2013 at 2:38 PM, Rafael Antognolli wrote: > Guys, anyone has noticed this? > > At least with mobile profile on desktop, if I try to scroll the > genlist inside elementary_test, it goes to the end and I can't go back > to the beginning anymore. Just try it and it should be obvious that > there's something wrong. > I saw that, opened elementary_config and chose the Mobile profile again (I was already using it, in theory), and it started working fine again. > Not sure if there's a ticket for this yet, but if there's no ticket > I'll just create a new one. > > Regards, > -- > Rafael Antognolli > > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Elementary scroll bad behavior
* Rafael Antognolli [2013-07-08 14:38:51 -0300]: > Guys, anyone has noticed this? > > At least with mobile profile on desktop, if I try to scroll the > genlist inside elementary_test, it goes to the end and I can't go back > to the beginning anymore. Just try it and it should be obvious that > there's something wrong. > > Not sure if there's a ticket for this yet, but if there's no ticket > I'll just create a new one. > > Regards, Bug confirmed :/ Go for it. > -- > Rafael Antognolli > > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Gustavo Lima Chaves Senior Developer @ Intel - Open Source Technology Center -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Elementary scroll bad behavior
Guys, anyone has noticed this? At least with mobile profile on desktop, if I try to scroll the genlist inside elementary_test, it goes to the end and I can't go back to the beginning anymore. Just try it and it should be obvious that there's something wrong. Not sure if there's a ticket for this yet, but if there's no ticket I'll just create a new one. Regards, -- Rafael Antognolli -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Eo: potential improvements
Hey guys, The hero Jeremy Zurcher has been playing around and looking for ways to improve Eo and address all the issues that have been raised by everyone. We revisited some old ideas, tried some new ideas and changed our compromises and preferences to better suit our needs (followed by the extensive trial period). We think we made things better and we'd like to hear your thoughts and suggestions. The code resides in devs/tasn/eo2. The differences are not major usage-wise (i.e eo_do), but are major internally and class-creation-wise. There's an example of the usage of the new API in the eo2test directory. The existing code-base hasn't been changed to use the new API, so there's not a lot to review. Eo2 is not complete, we'd like to hear your thoughts before finishing things. Major changes: 1. No more va_args, good ol' normal functions instead. 2. Functions are resolved in eo and then called directly, creating a "flatter" backtrace. 3. We can have return values (to some extent). 4. Less boiler-plate. 5. Looks like we'll be able to get rid of some code thanks to this change. 6. Possibly (probably) faster on platforms that pass parameters in registers. 7. Easier to do breakpoint on a specific eo_do call, instead of an implementation. What we'd still like to achieve: 1. Being able to drop the IDs in favour for more "friendly" IDs. It'd be best to find a way to use the function pointers (for example) as the IDs, but the problem is, that because function pointers are more "unknown" we can do less optimisations on them which we'd like to avoid. 2. Reduce more boiler-plate. Haven't been implemented yet: eo_do_super (among many other things). Additional comments: EO_FUNC - this one creates a function that resolves and returns the appropriate function. The functions created using this macro should be used instead of the current eo macros. This one can potentially be improved. eo2_do_start/end are just the entry/exit hooks of eo2_do (ref/unref and possibly other stuff in the future). Looking forward to hearing what you have to say. -- Tom. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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: efreet: Low priority for cache rebuild
Hello.
On 06/20/2013 12:54 PM, Sebastian Dransfeld - Enlightenment Git wrote:
> englebass pushed a commit to branch master.
>
> commit 58fc3a8f32d6fe71910ee0479afc3c8478c12540
> Author: Sebastian Dransfeld
> Date: Thu Jun 20 13:53:54 2013 +0200
>
> efreet: Low priority for cache rebuild
We finally are back on track trying to get a mingw (cross compile for
windows) build working with jenkins. This is the first error I get when
trying to come through the efl build now.
resources.h is not available on windows systems it seems. (Not using it
at all just trying to keep it working for people that do :))
Was the original ecore_exe_run_priority_* better in this regard?
regards
Stefan Schmidt
> ---
> src/bin/efreet/efreet_desktop_cache_create.c | 3 +++
> src/bin/efreet/efreet_icon_cache_create.c| 3 +++
> src/bin/efreet/efreetd.c | 4
> src/bin/efreet/efreetd_cache.c | 9 -
> 4 files changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/src/bin/efreet/efreet_desktop_cache_create.c
> b/src/bin/efreet/efreet_desktop_cache_create.c
> index db3118c..17f41e3 100644
> --- a/src/bin/efreet/efreet_desktop_cache_create.c
> +++ b/src/bin/efreet/efreet_desktop_cache_create.c
> @@ -5,6 +5,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
> #include
> @@ -250,6 +252,7 @@ main(int argc, char **argv)
> }
> extra_dirs = eina_list_sort(extra_dirs, -1, EINA_COMPARE_CB(strcmp));
>
> +setpriority(PRIO_PROCESS, 0, 19);
> /* init external subsystems */
> if (!eet_init()) goto eet_error;
> if (!ecore_init()) goto ecore_error;
> diff --git a/src/bin/efreet/efreet_icon_cache_create.c
> b/src/bin/efreet/efreet_icon_cache_create.c
> index a4f774c..7473280 100644
> --- a/src/bin/efreet/efreet_icon_cache_create.c
> +++ b/src/bin/efreet/efreet_icon_cache_create.c
> @@ -6,6 +6,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
> #include
> @@ -768,6 +770,7 @@ main(int argc, char **argv)
> flush = EINA_TRUE;
> }
>
> +setpriority(PRIO_PROCESS, 0, 19);
> if (!eet_init()) return -1;
> if (!ecore_init()) return -1;
>
> diff --git a/src/bin/efreet/efreetd.c b/src/bin/efreet/efreetd.c
> index 97b5162..d3f6d8c 100644
> --- a/src/bin/efreet/efreetd.c
> +++ b/src/bin/efreet/efreetd.c
> @@ -2,6 +2,9 @@
> # include
> #endif
>
> +#include
> +#include
> +
> #include
> #include
>
> @@ -34,6 +37,7 @@ main(int argc, char *argv[])
> if (!dbus_init()) goto dbus_error;
> if (!cache_init()) goto cache_error;
>
> + setpriority(PRIO_PROCESS, 0, 19);
> ecore_main_loop_begin();
>
> cache_shutdown();
> diff --git a/src/bin/efreet/efreetd_cache.c
> b/src/bin/efreet/efreetd_cache.c
> index 4d7fd9d..c286b13 100644
> --- a/src/bin/efreet/efreetd_cache.c
> +++ b/src/bin/efreet/efreetd_cache.c
> @@ -42,7 +42,6 @@ static Eina_Bool
> icon_cache_update_cache_cb(void *data EINA_UNUSED)
> {
> char file[PATH_MAX];
> - int prio;
>
> icon_cache_timer = NULL;
>
> @@ -55,9 +54,6 @@ icon_cache_update_cache_cb(void *data EINA_UNUSED)
> if ((!icon_flush) && (!icon_exts)) return ECORE_CALLBACK_CANCEL;
>
> /* TODO: Queue if already running */
> - prio = ecore_exe_run_priority_get();
> - ecore_exe_run_priority_set(19);
> -
> snprintf(file, sizeof(file),
> "%s/efreet/" MODULE_ARCH "/efreet_icon_cache_create",
> eina_prefix_lib_get(pfx));
> @@ -90,7 +86,6 @@ icon_cache_update_cache_cb(void *data EINA_UNUSED)
> icon_flush = EINA_FALSE;
> icon_cache_exe =
> ecore_exe_pipe_run(file,
> ECORE_EXE_PIPE_READ|ECORE_EXE_PIPE_READ_LINE_BUFFERED, NULL);
> - ecore_exe_run_priority_set(prio);
>
> return ECORE_CALLBACK_CANCEL;
> }
> @@ -109,7 +104,6 @@ static Eina_Bool
> desktop_cache_update_cache_cb(void *data EINA_UNUSED)
> {
> char file[PATH_MAX];
> - int prio;
>
> desktop_cache_timer = NULL;
>
> @@ -119,8 +113,6 @@ desktop_cache_update_cache_cb(void *data EINA_UNUSED)
> return ECORE_CALLBACK_CANCEL;
>}
> desktop_queue = EINA_FALSE;
> - prio = ecore_exe_run_priority_get();
> - ecore_exe_run_priority_set(19);
>
> snprintf(file, sizeof(file),
> "%s/efreet/" MODULE_ARCH "/efreet_desktop_cache_create",
> @@ -140,7 +132,6 @@ desktop_cache_update_cache_cb(void *data EINA_UNUSED)
> INF("Run desktop cache creation: %s", file);
> desktop_cache_exe =
> ecore_exe_pipe_run(file,
> ECORE_EXE_PIPE_READ|ECORE_EXE_PIPE_READ_LINE_BUFFERED, NULL);
> - ecore_exe_run_priority_set(prio);
>
> return ECORE_CALLBACK_CANCEL;
> }
>
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
enlightenment-devel mailing li
[E-devel] Weekly news from the automated build and QA front
Hello. This should give everyone an overview over what has happened in the last week regarding our continuous integration builds, unit tests and coverage as well as all static analyser runs and things like address-sanitizer. The numbers in parentheses reflect the values from last week to give you a trend. CI: o Found problem with els_pane still listed in POTFILES. Always check POTFILES when removing files. :) o Overall build statistic: 12.7% (13.39%) failed and 87.3% (86.61%) succeeded. https://build.enlightenment.org/ clang scan-build: o EFL scan-build reports 596 (596) issues. https://build.enlightenment.org/job/nightly_efl_clang_x86_64/lastSuccessfu lBuild/artifact/scan-build/build/ o The last clang build is from 2013-06-27 so the value has not changed. Daniel is looking into what causes our clang nightlies to fail. Exactness: o Problems with fonts o Still waiting for the first successful run on jenkins Unit tests: o 266 unit tests for efl and none failing Coverage: o EFL total coverage is at 25.2% (25.2%) lines and 28.0% (28.0%) functions o We could improve this quite a bit :) Coverity: o EFL: Outstanding defects 533 (549) with a density of 1.03 (1.05). 16 defects fixed since last build and 2 added. o Elm: Outstanding defects 41 (77) with a density of 0.20 (0.37). 29 defects fixed since last build and 4 added. o E: Outstanding defects 203 (203) with a density of 0.75 (0.74). 0 defects fixed since last build and 0 added. Quite a few fixes hit elementary and also efl. Thanks a lot to everybody who worked on this. This keeps me motivated to do such things here when I see a real benefit coming out of it. :) If anybody wants to see something added here let me know and be my guest. regards Stefan Schmidt -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Question about getting content of item in Genlist
Hi Daniel, On 07/06/2013 07:03 AM, Daniel Juyung Seo wrote: > Yes exactly. > The list of contents parts are described in the genlist item style in edc. > So you can retrieve the data from genlist item edje object. > But the problem is that we don't want to expose the genlist item's edje > object. > Refer the following discussions wrt this. > http://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg46815.html > http://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg48240.html > http://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg52185.html Thanks for explanation why edje object for genlist not exposed. > > So in elementary accessibility, application sets the list of item content > by calling elm_object_item_access_order_set(). > Please refer the following sample. > http://git.enlightenment.org/core/elementary.git/tree/src/bin/test_access.c#n118 > > Maybe you can just use elementary accessibility :) So, if I understand this correctly, application is responsible for filling accessible data content for items in genlist? In other words, when application don't care about setting accessible content parts using elm_object_item_access_order_set(), then elementary accessibility won't be very helpful? BR, Radoslaw Jablonski > Thanks. > > Daniel Juyung Seo (SeoZ) > > > > > On Sat, Jul 6, 2013 at 3:04 AM, Rafael Antognolli wrote: > >> Actually, isn't possible to just access the genlist item group/class, >> and get the data.item "texts", and data.item "contents"? >> >> The parts defined in these fields should be the ones which are called >> by the item_content_get and item_label_get functions, aren't they? >> >> Regards, >> >> On Thu, Jul 4, 2013 at 9:50 PM, ChunEon Park wrote: >>> Currently, no. >>> >>> If the theme supports extra content/text parts, those names should be >> documented. >>> Only wiith just part type/part name, we aren't sure what those parts are >> designed for actually. >>> If those parts were designed for only internal stage, then you should >> not access them even if you can get the parts info. >>> I think app or somewhere needs to register the valid parts names so as >> to access the parts by you. >>> >>> >>> -Regards, Hermet- >>> >>> -Original Message- >>> From: "Radosław Jabłoński" >>> To: "Enlightenment-devel"; >>> Cc: >>> Sent: 2013-07-04 (목) 22:14:30 >>> Subject: [E-devel] Question about getting content of item in Genlist >>> >>> Hello all, >>> >>> I'm working on library that will integrate Gnome Accessibility Toolkit >>> (ATK) with EFL libraries, so I'm interested in retrieving all kinds of >>> data that is displayed by elementary widgets. >>> >>> Actually I'm stuck on retrieving widget contents from items that are >>> stored in Genlist container. >>> I know that getting Evas_Object from Elm_Object_Item is possible via >>> 'elm_object_item_part_content_get' function - it works great when I know >>> value of swallow_part string. For "default" theme things are pretty easy >>> - I know that content can be in parts "elm.text", "elm.swallow.icon" and >>> "elm.swallow.end". But (AFAIK) problem is that content string names can >>> have custom values - and I can't hardcode every possible content part >>> string that could be used by EFL Tizen apps:) >>> >>> So, is there any method to dynamically get all possible content part >>> names that are used by target item in Genlist? >>> >>> Thanks in advance for any help. >>> BR, >>> Radoslaw Jablonski >>> >>> >> -- >>> This SF.net email is sponsored by Windows: >>> >>> Build for Windows Store. >>> >>> http://p.sf.net/sfu/windows-dev2dev >>> ___ >>> enlightenment-devel mailing list >>> enlightenment-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >>> >>> >> -- >>> This SF.net email is sponsored by Windows: >>> >>> Build for Windows Store. >>> >>> http://p.sf.net/sfu/windows-dev2dev >>> ___ >>> enlightenment-devel mailing list >>> enlightenment-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> >> >> -- >> Rafael Antognolli >> >> >> -- >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-dev2dev >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _
