[E-devel] ecore_path questions
Hey I have 2 qestions about ecore_path: 1) about ecore_path_group_new, the documentation says that if an error occured, then 0 is returned. But I see a return -1; Shouldn't the function return 0 instead ? Also, if ecore_list_new return NULL, shouldn't we also return an error (0 or -1, according to the convention used...) ? 2) in __ecore_path_group_find_id, there is no check to see if id is positive or not (or non negative, if the error is -1). Is it normal ? thank you Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore_path questions
Vincent Torri wrote: Hey I have 2 qestions about ecore_path: 1) about ecore_path_group_new, the documentation says that if an error occured, then 0 is returned. But I see a return -1; Shouldn't the function return 0 instead ? Also, if ecore_list_new return NULL, shouldn't we also return an error (0 or -1, according to the convention used...) ? This is an error, efl should return 0 on error. 2) in __ecore_path_group_find_id, there is no check to see if id is positive or not (or non negative, if the error is -1). Is it normal ? Why do you need to check the id? If it is negative you wont find a group. Unnecessary looping, but no error. Sebastian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: e kwo
--- configure.in 21 Oct 2007 13:10:23 - 1.232
+++ configure.in 3 Nov 2007 10:32:42 - 1.233
@@ -95,9 +95,6 @@
ENLIGHTENMENT_ROOT=`eval echo ${DATADIR}/e16`
ENLIGHTENMENT_BIN=`eval echo ${bindir}`
ENLIGHTENMENT_LIB=`eval echo ${libdir}`
-AC_SUBST(ENLIGHTENMENT_ROOT)
-AC_SUBST(ENLIGHTENMENT_BIN)
-AC_SUBST(ENLIGHTENMENT_LIB)
AC_DEFINE_UNQUOTED(ENLIGHTENMENT_ROOT, $ENLIGHTENMENT_ROOT, [The
installation root directory])
AC_DEFINE_UNQUOTED(ENLIGHTENMENT_BIN, $ENLIGHTENMENT_BIN, [The installation
bin directory])
AC_DEFINE_UNQUOTED(ENLIGHTENMENT_LIB, $ENLIGHTENMENT_LIB, [The installation
lib directory])
You should pass bindir and al to the Makefile with -D. It's the
recommended way (from autoconf manual:
http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_mono/autoconf.html#SEC179).
The problem begin that they are based on ${prefix} and ${prefix} is not
evaluated in configure.in
you can see how I did in edje/src/bin/Makefile.am
regards
Vincent
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: e kwo
Vincent Torri wrote:
--- configure.in 21 Oct 2007 13:10:23 - 1.232
+++ configure.in 3 Nov 2007 10:32:42 - 1.233
@@ -95,9 +95,6 @@
ENLIGHTENMENT_ROOT=`eval echo ${DATADIR}/e16`
ENLIGHTENMENT_BIN=`eval echo ${bindir}`
ENLIGHTENMENT_LIB=`eval echo ${libdir}`
-AC_SUBST(ENLIGHTENMENT_ROOT)
-AC_SUBST(ENLIGHTENMENT_BIN)
-AC_SUBST(ENLIGHTENMENT_LIB)
AC_DEFINE_UNQUOTED(ENLIGHTENMENT_ROOT, $ENLIGHTENMENT_ROOT, [The
installation root directory])
AC_DEFINE_UNQUOTED(ENLIGHTENMENT_BIN, $ENLIGHTENMENT_BIN, [The
installation bin directory])
AC_DEFINE_UNQUOTED(ENLIGHTENMENT_LIB, $ENLIGHTENMENT_LIB, [The
installation lib directory])
You should pass bindir and al to the Makefile with -D. It's the
recommended way (from autoconf manual:
http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_mono/autoconf.html#SEC179).
The problem begin that they are based on ${prefix} and ${prefix} is not
evaluated in configure.in
you can see how I did in edje/src/bin/Makefile.am
I know. I just don't like the recommended way. Maybe later :)
/Kim
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Nightly build log for E17 on 2007-11-03 07:08:32 -0700
Build log for Enlightenment DR 0.17 on 2007-11-03 07:08:32 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: engage http://download.enlightenment.org/tests/logs/engage.log epdf http://download.enlightenment.org/tests/logs/epdf.log evolve http://download.enlightenment.org/tests/logs/evolve.log Packages with no supported build system: esmart_rsvg, exorcist, python-efl, Packages skipped: camE, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, cpu, deskshow, eclair, ecore, edb, e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, eflpp, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emu, engrave, engycad, enhance, enity, enterminus, enthrall, entice, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, ewl, examine, exhibit, exml, expedite, express, extrackt, feh, flame, forecasts, gevas2, iconbar, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, net, news, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Discussion about Evas perfs for scrolling
Hi guys! Evas is a really great lib with very good performances to render a lot of objects, but I think it has one major drawback: it is quite slow when we have to scroll contents (iconbox, list-view, text-view, ...). Indeed, for now, in order to implement this scrolling effect, we have to move all the objects contained in the view. This means that the *entire* view has to be redrawn each time the user scrolls, even by a 1-pixel offset. And if this is a fullscreen view on a 1600x1200 screen, it will require a very powerful CPU in order to have a really smooth scrolling, and I don't think this is acceptable. If we compare the scrolling performances of Evas with the ones of GTK or QT, it's easily noticeable than GTK/QT are *far* more efficient for scrolling! So.. how do they do that? Well, it seems they just don't redraw the entire view, but just the elements that were not previously visible in the view, and that now are visible. Indeed, when scrolling, a big part of the content was already visible and then rendered, and would just require to be translated to the right position. There is indeed no need to redraw the whole view, but just the elements that weren't visible on the previous frame. Now, how can we do this in Evas? I see two solutions here: 1/ We try to detect the areas that can be just translated instead of being redrawn. It would imply no change in current applications in order to get benefit of it, but the algorithm behind it is far from being simple, and it may even use more CPU than it would save from avoiding the whole redraw thing. So, I don't think it's the good way to do that. 2/ We could also use the viewport feature of Evas for this. When scrolling, instead of moving the objects, we could simply move the viewport in the opposite direction. For example, if we'd like a long-scrolled iconbox, we would have a huge Evas containing all the icon-objects of the iconbox, but with a small viewport representing the iconbox-view. Now, when scrolling, no need to move all the icon-objects, we would just have to move the viewport. When moving the viewport, we could then translate all the pixels that are common to the two viewport's geometries, and redraw only the areas that were not in the previous viewport-geometry. This can be done really easily Advantages: it should be a lot easier to implement in Evas, and it will probably give better results. Drawbacks: - Apps would need some adaptations in order to get benefit of this and the scrolled-views would have to use their own buffer-engined Evas (which would mean a bigger memory consumption, but the first solution would also increase memory consumption anyway). - Evas and Evas' engines would need to support viewports that are not placed at 0,0, and viewports that can be moved. But I don't think it should be too hard So, what do you think about this? Any other solution in mind? I'll be glad to hear your opinions! :) Cheers, Simon TRENY MoOm - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] GCC attributes usage
Hi guys, I tried to compile CVS with LDFLAGS=-fvisibility=hidden and to my double surprise: 1) most modules built fine, 2) things that would benefit most, don't use it :-/ Modules that miss EAPI (or __attribute__ ((visibility(default: e_dbus efreet etk ewl Also, please try to use the other hints, like pure, const, malloc, unused, nonnull, warn_unused_result. They're really easy to use, just define some macros with one or more of them using a clever name and we might getter some better results. You might get some examples from info gcc and from google. It's a minor optimization, but given the required work, it worth it. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17's Direction and Development
On Thu, 1 Nov 2007 08:46:05 -0400 Hisham Mardam Bey [EMAIL PROTECTED] babbled: actually no - it was meant to be BOTH a file selector back-end AND a simple filemanager. there is no point making 2 of them separate. they do the same thing. list files. Granted, but if the file manager functionality is going to take a lot of time to complete we should just put it on hold and work on the bugs in the TODO. it shouldn't take a tonne of time to complete. though from what you say you are suggesting a freeze to fix bugs - not finish the TODO ? it is really just these 2 big ones with smaller cleanups that need doing - tho default theme cleanup is not a small task BTW - i'm commenting the .edc heavily. I'm not criticizing how these things are designed or saying they are bad or extra features. I am just saying that as it stands, they need a good amount of work and have the tendency to grow. We should say that we want to make them do a, b, and c, and freeze anything else. i agree - the wizard i know i only want certain functionality - it's even modular in and of itself, so we only put the modules in we need. i even have a proposed list of modules we need to do - it's not long. it's in comments in the wizard code. most are simple. i'd be happy to drop some (xrender vs software test and just use software anyway), drop default ibar apps (just ship with a default set anyway - but make that a separate file for the list so it can be customised per distribution), drop the keybindings question and default wallpaper and theme q's - most of the rest are really trivial question pages. it just needs momentum and examples. the fm has more work - but not a lot more. it's so close i don't think it should be all dropped. it's been on the todo forever. after that we have done all major todo items left - the rest are minor things, cleanups, fixing gaps in complete functionality etc. the problem is the pace. there are lots of TODO items - most not being done. in doing efm and wizard - i am trying to knock of some of the big fat items and get them started/going/ to a state of relative health. i agree we need to knuckle down on those. the wizard core *i think) is done. its' a matter of pages to do the setup. we can make it simple - but we do need it. we have enough problems with users asking about empty/blank app menus and other things that we need to fix in code on setup (i.e. - find all the xdg menus and ask user which one they want etc.). So I guess the next move is to *try* and organize this mess and come up with a rough schedule for things. I know we dont usually do this kind of thing, but I firmly believe that if we dont set a schedule, nothing is ever going to be done anytime soon. we can set a schedule - and i will bet we will slip. if we set milestones/tasks and just do those - then we can get it done at a pace that allows that. if you want a schedule from me - i will currently put in 0 hours per week for the next 2 months as an allocation - why? i'm moving countries and who knows what time i will have. in essence those milestones are IN the TODO. i'm removing fm todo items i think can be dropped right now. i've dropped some other items. see cvs commit. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] GCC attributes usage
In the case of ewl, most of the functions are public so that external modules can inherit and override defaults. Any truly private functions are static. Did you see something specific in ewl that would benefit? On 11/4/07, Gustavo Sverzut Barbieri [EMAIL PROTECTED] com wrote: Hi guys, I tried to compile CVS with LDFLAGS=-fvisibility=hidden and to my double surprise: 1) most modules built fine, 2) things that would benefit most, don't use it :-/ Modules that miss EAPI (or __attribute__ ((visibility(default: e_dbus efreet etk ewl Also, please try to use the other hints, like pure, const, malloc, unused, nonnull, warn_unused_result. They're really easy to use, just define some macros with one or more of them using a clever name and we might getter some better results. You might get some examples from info gcc and from google. It's a minor optimization, but given the required work, it worth it. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get. splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge. net/lists/listinfo/enlightenment-devel rceforge. net/lists/listinfo/enlightenment-devel rceforge. net/lists/listinfo/enlightenment-devel On 11/4/07, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: Hi guys, I tried to compile CVS with LDFLAGS=-fvisibility=hidden and to my double surprise: 1) most modules built fine, 2) things that would benefit most, don't use it :-/ Modules that miss EAPI (or __attribute__ ((visibility(default: e_dbus efreet etk ewl Also, please try to use the other hints, like pure, const, malloc, unused, nonnull, warn_unused_result. They're really easy to use, just define some macros with one or more of them using a clever name and we might getter some better results. You might get some examples from info gcc and from google. It's a minor optimization, but given the required work, it worth it. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
