Re: [E-devel] ELFE Causes Segfault in Latest E
Please ignore this message. All is fine with this module. The state of my profile configurations... Not so much. On Tue, Dec 11, 2012 at 1:47 AM, Jeff Hoogland jeffhoogl...@linux.comwrote: If anyone has time could you look into updating ELFE to working with the latest EFL (combined in SVN) and E17 SVN? Right now it compiles for me, but any profile in which it is loaded instantly gets a crash window as long as ELFE is loaded. Use this launcher in my tablet profile as it is better than the illume default home. Regards, -- ~Jeff Hoogland http://jeffhoogland.com/ Thoughts on Technology http://jeffhoogland.blogspot.com/, Tech Blog Bodhi Linux http://bodhilinux.com/, Enlightenment for your Desktop -- ~Jeff Hoogland http://jeffhoogland.com/ Thoughts on Technology http://jeffhoogland.blogspot.com/, Tech Blog Bodhi Linux http://bodhilinux.com/, Enlightenment for your Desktop -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri IN trunk/efl: . m4
On 10/12/12 09:45, Gustavo Sverzut Barbieri wrote: On Monday, December 10, 2012, Stefan Schmidt wrote: Hello. On 07/12/12 23:17, Enlightenment SVN wrote: Log: efl: almost final ecore/evas/ecore-evas options integration. Many changes in this commit, but overall it should work. If not let me know. * ECORE_CHECK_X_EXTENSION() will now fail if Xlib extension is not found. It seems buildbot got hit by this. checking for X11/extensions/Xinerama.h... no configure: error: Missing X11/extensions/Xinerama.h make: *** [/srv/buildbot/slaves/efl/quick-linux/build/build/efl/stamps/configure] Error 1 I installed libxinerama and libxscrnsaver on e3 now but it feels kinda like a regression as it did work fine without them before. Before it autodetected all deps. We agreed this wouldn't happen with EFL single tree anymore. We have just some minor options for not-so-common extensions such as xinput2. But even with options it will not autodetect, you must enable or disable if your system is different from default. Well, I also don't want to have them autodetect so the change itself is fine by me. I somehow expected to see a mail about it when it comes in. Maybe it was the commit mail in this case. :) Anyway, I like the change. Just a bit surprised. regards Stefan Schmidt -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo debug helper
Hey Tom, You are right. Don't tell me I know, I am always right! ;-) Following the script. Next step, how can I install it in /opt/e17? Which file do I need to modify? Script: class Eo_step(gdb.Command): def __init__(self): gdb.Command.__init__(self, eo_step, gdb.COMMAND_OBSCURE) def invoke (self, arg, from_tty): # While libeo is not reached, we step into while gdb.solib_name(gdb.selected_frame().pc()).find(libeo.so) == -1: # step by one assembly instruction, no print gdb.execute(stepi, False, to_string=True) # While we are in libeo or in an unknown function, we step into while (gdb.selected_frame().function() == None) or (gdb.solib_name(gdb.selected_frame().pc()).find(libeo.so) != -1): # step by one assembly instruction, no print gdb.execute(stepi, False, to_string=True) print Stopped at file + gdb.selected_frame().find_sal().symtab.filename+ line + str(gdb.selected_frame().find_sal().line) + function + str(gdb.selected_frame().function()) Eo_step() Daniel On 12/11/2012 01:20 AM, Tom Hacohen wrote: Hey Daniel, I found this in python.c in the gdb source tree: /* Implementation of gdb.solib_name (Long) - String. Returns the name of the shared library holding a given address, or None. */ static PyObject * gdbpy_solib_name (PyObject *self, PyObject *args) So just use gdb.solib_name... I just skimmed through the file, maybe there's more there I've missed, sounds like exactly what you are looking for. On Mon, Dec 10, 2012 at 9:18 AM, daniel.za...@samsung.com mailto:daniel.za...@samsung.com daniel.za...@samsung.com mailto:daniel.za...@samsung.com wrote: Hi Tom, 1. I will check it, maybe just print line and which file 2. I don't find how to get the library name. Sure it will be easier with the library. 3. I understand the point but for the moment I don't have a solution. I will investigate when time is with me (not so english, this sentence). If you find something on your side, tell me. Daniel On 12/10/2012 12:44 AM, Tom Hacohen wrote: Hey Daniel, Good thing that it works and I'm happy you improved it so fast, but I still have a couple of comments: 1. print You reached the function + str(gdb.selected_frame().function()) - It's probably better to change it to fit the gdb style of info messages better. It doesn't look like something you'd see out of gdb. 2. (yes I stay with that, it seems easier than with the library) - It just means you are doing something wrong as if you have a properly stripped binary there's no information about eo.c so it just won't work. Furthermore, I don't understand how it is easier, both are just a single test and it's a matter of just accessing a different property. 3. if (self.priv_current_line != self.priv_prev_line) or (str(self.priv_current_symtab) != str(self.priv_prev_symtab)): - If I understand it correctly it seems that you are looking until the line has changed. This isn't good because if for example you do: eo_do(obj, SET_A, get_some_number()) it'll fail as it'll get into the second function, and not the eo call. I don't know, maybe that's what you expect it to do, and then it's fine, but then the second loop kinda doesn't make sense... If you use the so name you can do something as simple as: 1. stepi until we get into libeo.so. 2. stepi until we get out of libeo.so. Very simple, very easy. No variables, state or anything. What do you think? -- Tom. On Sun, Dec 9, 2012 at 12:39 PM, daniel.za...@samsung.com mailto:daniel.za...@samsung.com daniel.za...@samsung.com mailto:daniel.za...@samsung.com wrote: Hi Tom, It works with stepi. The stepping process consists now in two phases: - stepping until we are no more in the the caller function - stepping while function name unknown or still in Eo.c (yes I stay with that, it seems easier than with the library) It now supports Eo with and without symbols. Code is following. Let's see soon in SVN. Daniel class Eo_step(gdb.Command): def __init__(self): gdb.Command.__init__(self, eo_step, gdb.COMMAND_OBSCURE) def invoke (self, arg, from_tty): self.priv_prev_line = gdb.selected_frame().find_sal().line self.priv_prev_symtab = gdb.selected_frame().find_sal().symtab while True: # step by one assembly instruction gdb.execute(stepi, False, to_string=True) # While under same code line self.priv_current_line = gdb.selected_frame().find_sal().line self.priv_current_symtab =
Re: [E-devel] Memory Leak in Eet + OpenSSL
Hello again. I've tested that same example I sent with eet-1.7.3, released at Dec 7th and the leak still happens. I haven't tested the eet from trunk, because after you had moved many libraries to a single project (efl) it became a bit hard to build eet here (now I also have to have installed the dependencies of the other libraries which I don't use, like x-stuff, etc. :-( ). But I don't think this problem has been resolved in trunk, because when I got a diff between the file eet_cipher.c in 1.7.3 and in the trunk and there's no code related to that problem. Have anyone else ran in valgrind the code I sent to reproduce the bug or confirm if it's a bug in eet or openssl (or even in my code)? 2012/12/10 Leandro Santiago leandrosansi...@gmail.com Yes, I can. I will do it tomorrow at work, as soon the svn server returns working. 2012/12/10 Luis Felipe Strano Moraes luis.str...@gmail.com Could you please re-run the test either with the latest stable or with current SVN HEAD? Would make it much easier for people to test it. BR, --lf On Mon, Dec 10, 2012 at 12:56 PM, Leandro Santiago leandrosansi...@gmail.com wrote: Ops,I forgot to say. I'm using ubuntu 12.04 amd64. 2012/12/10 Leandro Santiago leandrosansi...@gmail.com Hello to all. As the e server is down, I'm sending this report to this mailing list. I think there's a memory leak in eet when openssl is used as cipher engine. I wrote a small test case, which is attached, as well the output of the executable in valgrind (--tool=memcheck and --leak-check=full). I'm using eet 1.7.1 and openssl 1.0.1c. -- - Sent from my Atari -- - Sent from my Atari -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Luís Felipe Strano Moraes http://www.strano.org -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Sent from my Atari -- - Sent from my Atari -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH][RFC] Add support to context-dependent translation.
This patch makes use of pgettext() function which is provided in gettext.h The function has two arguments -- the first argument is a context (arbitrary string), the second one is a message itself. This allows translators to have different translations for several equal messages depending on their context. For example, in E the message System is used multiple times. But sometimes it is just System and should be translated as a noun, and sometimes it's something like System Themes and should be translated as an adjective. With the help of pgettext() it's possible to split off the second usecase to its own part. Following example demonstrates the outcome for italian: msgid System msgstr Sistema msgctxt System [noun] msgid System msgstr Sistemici Here the context is System [noun] which means that the message will be used as a part of a sentence like System Themes or System Wallpappers. Some more examples are provided below in the patch. Some possible issues with this patch are: * I'm not sure if gettext.h could be placed in the code. It looks like it is under GPL license. Are there any other alternatives to gettext.h where i can still the pgettext() definition from? * Some sane rules should be worked out on which messages could be split off into their own context to prevent making the pot excessively muddled. The patch is tested and it works just as expected. --- po/Makevars| 2 +- po/it.po | 66 ++--- po/ru.po | 60 +++-- src/bin/e_intl.h | 3 + src/bin/gettext.h | 280 + .../conf_display/e_int_config_desklock_fsel.c | 2 +- src/modules/conf_intl/e_int_config_imc.c | 2 +- src/modules/conf_theme/e_int_config_fonts.c| 2 +- src/modules/conf_theme/e_int_config_startup.c | 2 +- src/modules/conf_theme/e_int_config_theme.c| 6 +- src/modules/conf_theme/e_int_config_wallpaper.c| 4 +- src/modules/dropshadow/e_mod_config.c | 6 +- src/modules/gadman/e_mod_config.c | 2 +- src/modules/shot/e_mod_main.c | 8 +- 14 files changed, 374 insertions(+), 71 deletions(-) create mode 100644 src/bin/gettext.h diff --git a/po/Makevars b/po/Makevars index 090dd05..7c92776 100644 --- a/po/Makevars +++ b/po/Makevars @@ -9,7 +9,7 @@ top_builddir = .. # These options get passed to xgettext. XGETTEXT_OPTIONS = --keyword=_ --keyword=d_:1 --keyword=P_:1,2 \ - --keyword=dP_:1,2 --keyword=N_ --keyword=NP_:1,2 \ + --keyword=dP_:1,2 --keyword=N_ --keyword=NP_:1,2 --keyword=C_:1c,2 \ --keyword=EVRY_PLUGIN_BASE:1 --keyword=EVRY_ACTION_NEW:1 \ --keyword=ACTION_NEW:1 \ --from-code=UTF-8 --foreign-user diff --git a/po/it.po b/po/it.po index ad4a618..8d80471 100644 --- a/po/it.po +++ b/po/it.po @@ -721,17 +721,8 @@ msgstr Commuta il modulo specificato #: src/bin/e_actions.c:3417 src/bin/e_actions.c:3421 src/bin/e_configure.c:411 #: src/bin/e_int_config_modules.c:52 #: src/modules/conf_applications/e_int_config_apps.c:275 -#: src/modules/conf_display/e_int_config_desklock_fsel.c:87 -#: src/modules/conf_intl/e_int_config_imc.c:818 -#: src/modules/conf_theme/e_int_config_wallpaper.c:429 -#: src/modules/conf_theme/e_int_config_wallpaper.c:546 -#: src/modules/conf_theme/e_int_config_startup.c:258 -#: src/modules/conf_theme/e_int_config_theme.c:455 -#: src/modules/conf_theme/e_int_config_theme.c:830 -#: src/modules/conf_theme/e_int_config_theme.c:844 -#: src/modules/gadman/e_mod_config.c:252 src/modules/syscon/e_mod_main.c:31 -#: src/modules/syscon/e_mod_main.c:35 src/modules/syscon/e_mod_main.c:60 -#: src/modules/syscon/e_mod_main.c:129 +#: src/modules/syscon/e_mod_main.c:31 src/modules/syscon/e_mod_main.c:35 +#: src/modules/syscon/e_mod_main.c:60 src/modules/syscon/e_mod_main.c:129 msgid System msgstr Sistema @@ -2824,7 +2815,6 @@ msgid Shrink to Content Width msgstr Riduci alla larghezza del contenuto #: src/bin/e_int_shelf_config.c:213 src/modules/comp/e_mod_config.c:912 -#: src/modules/conf_theme/e_int_config_fonts.c:650 msgid Style msgstr Stile @@ -5469,6 +5459,19 @@ msgstr Seleziona uno sfondo... msgid Personal msgstr Personali +#: src/modules/conf_display/e_int_config_desklock_fsel.c:87 +#: src/modules/conf_intl/e_int_config_imc.c:818 +#: src/modules/conf_theme/e_int_config_wallpaper.c:429 +#: src/modules/conf_theme/e_int_config_wallpaper.c:546 +#: src/modules/conf_theme/e_int_config_startup.c:258 +#: src/modules/conf_theme/e_int_config_theme.c:455 +#: src/modules/conf_theme/e_int_config_theme.c:830 +#: src/modules/conf_theme/e_int_config_theme.c:844 +#: src/modules/gadman/e_mod_config.c:252 +msgctxt System [noun] +msgid System +msgstr Sistemici + #: src/modules/conf_display/e_int_config_desklock.c:80 msgid Screen Lock Settings msgstr
[E-devel] [Elm_colorselector]: palette resize issue and picker warning fix
Hi All, Please find attached bug fix patch for Colorselector. This patch fixes the resize issue in palette which happens when palette item size is given more than finger size. This patch also fixes a fixed: 1 1 warning shown in picker(New addition to colorselector). This warning can be seen when we shift from both mode(palette+component) to picker mode and back to both mode. Change description: elm_colorselector: Palette items resize issue when item size is more than finger size and fixed: 1 1 warning in picker fixed. Signed-Off by: Shilpa Singh(shilpa.si...@samsung.com) Thanks Regards Shilpa Singh elm_colorselector.patch Description: Binary data -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Memory Leak in Eet + OpenSSL
Hello, On Tue, Dec 11, 2012 at 8:03 PM, Leandro Santiago leandrosansi...@gmail.com wrote: Hello again. I've tested that same example I sent with eet-1.7.3, released at Dec 7th and the leak still happens. I haven't tested the eet from trunk, because after you had moved many libraries to a single project (efl) it became a bit hard to build eet here (now I also have to have installed the dependencies of the other libraries which I don't use, like x-stuff, etc. :-( ). But I don't think this problem has been resolved in trunk, because when I got a diff between the file eet_cipher.c in 1.7.3 and in the trunk and there's no code related to that problem. Have anyone else ran in valgrind the code I sent to reproduce the bug or confirm if it's a bug in eet or openssl (or even in my code)? It should be fixed in svn (both trunk and branch). -- Cedric BAIL -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Proxy Image
Hello, I tested the proxy image for using it. I expected the proxy image is shown whole ,even if the source object is clipped. But if the source object is clipped, the proxy image is clipped too. I want to show the whole copied image regardless of the clip of the source object. I think this request is necessary. Please help me. ok - sorry for the delay. your'e one of my older to get to mails. clipping and proxy/map: clips that are OUTSIDE of an object (outside a smart object for example) should not apply to the rendering of the map buffer proxy uses. i spent a lot of effort in the rendering code to ensure this doesnt happen. for map - which is the same basis for proxy... BUT.. i think they have different render paths... and this may have a bug. right now this needs to get chalked up as a bug. if you have a test case to reproduce - that would be good. and right now... given the size of my backlog... this is going to have to just go on a long list of bugs to fix. one way to put it on my list is to file a bug on trac... another is to send another email here with the reproduction case and i'll mark it and it'll sit in my queue :) Definitely a bug, and I'll see if I can take a look at it soon. Do you have a bug # or a reproduction case? Regards, nash [Rising from the dead] -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Evil 1.7.3 is missing
All is in the title, evil is missing in the latest release. -- Nicolas Aguirre Mail: aguirre.nico...@gmail.com Web: http://enna.geexbox.org Blog: http://dev.enlightenment.fr/~captainigloo/ -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evil 1.7.3 is missing
Nicolas, sorry about that. We do not in fact have a proper stable branch for evil, so for 1.7.2 Vincent generated a tarball for me. As far as I can tell, you can just use the 1.7.2 tarball since there should have not been any changes, but lets wait for Vincent to chime in since he is the one who knows best about these devilish issues. Best regards, --lf On Tue, Dec 11, 2012 at 10:26 AM, Nicolas Aguirre aguirre.nico...@gmail.com wrote: All is in the title, evil is missing in the latest release. -- Nicolas Aguirre Mail: aguirre.nico...@gmail.com Web: http://enna.geexbox.org Blog: http://dev.enlightenment.fr/~captainigloo/ -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Luís Felipe Strano Moraes http://www.strano.org -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-intl] [PATCH][RFC] Add support to context-dependent translation.
On Tue, 11 Dec 2012 12:26:42 + Sérgio Marques smarque...@gmail.com wrote: 2012/12/11 Igor Murzov e-m...@date.by This patch makes use of pgettext() function which is provided in gettext.h The function has two arguments -- the first argument is a context (arbitrary string), the second one is a message itself. This allows translators to have different translations for several equal messages depending on their context. For example, in E the message System is used multiple times. But sometimes it is just System and should be translated as a noun, and sometimes it's something like System Themes and should be translated as an adjective. With the help of pgettext() it's possible to split off the second usecase to its own part. Following example demonstrates the outcome for italian: msgid System msgstr Sistema msgctxt System [noun] msgid System msgstr Sistemici Here the context is System [noun] which means that the message will be used as a part of a sentence like System Themes or System Wallpappers. Some more examples are provided below in the patch. For what I understand everytime that appears msgctxt System [noun] this is used for System Theme/wallpaper... No, msgid is still the same. Context is just a hint for translators. Context-dependent translation will allow you to have different msgstrs for equal msgids. Is this correct? Cause for Portuguese we don´t use uppercase in these sentences. So everytime it appears I must translate it as lower case. The message will be used in various import dialogs. It is paired with Personal and the same style should apply: msgid Personal msgstr Personali msgctxt System [noun] msgid System msgstr Sistemici -- Igor Regards -- Sérgio Marques -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: woohyun IN trunk/elementary: . src/lib
On Tue, Dec 11, 2012 at 5:33 AM, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
elementary/naviframe : Remove dummy_edje. Naviframe should be shown with
at least one item, and don't have to care about the state there is no item.
Additionally, it's not a smart member of naviframe, there is no
guarantee when this object will be deleted.
Oh, really? What about having a naviframe with no items temporarily in your
code?
I did that because layout's code, the parent class of naviframe, always
assumes there's the resize object there for its class functions (go check
it yourself). If there is none - crash.
I was being set as smart member via resize_object_set(). Please consider
reverting it.
Regards,
Author: woohyun
Date: 2012-12-10 23:33:27 -0800 (Mon, 10 Dec 2012)
New Revision: 80628
Trac: http://trac.enlightenment.org/e/changeset/80628
Modified:
trunk/elementary/ChangeLog trunk/elementary/NEWS
trunk/elementary/src/lib/elc_naviframe.c
Modified: trunk/elementary/ChangeLog
===
--- trunk/elementary/ChangeLog 2012-12-11 03:51:45 UTC (rev 80627)
+++ trunk/elementary/ChangeLog 2012-12-11 07:33:27 UTC (rev 80628)
@@ -802,3 +802,7 @@
* Make sure private data is not NULL in elm_interface_scrollable.
* Correctly handle failure case in _x11_notify_handler_image.
* Fix missuse of EINA_INLIST_FOREACH in elm_transit.c.
+
+2012-12-11 WooHyun Jung
+
+ * Remove dummy object from elm_naviframe.
Modified: trunk/elementary/NEWS
===
--- trunk/elementary/NEWS 2012-12-11 03:51:45 UTC (rev 80627)
+++ trunk/elementary/NEWS 2012-12-11 07:33:27 UTC (rev 80628)
@@ -89,6 +89,7 @@
* Make sure private data is not NULL in elm_interface_scrollable.
* Correctly handle failure case in _x11_notify_handler_image.
* Don't manipulate dead memory in Eina_Inlist in elm_transit.c.
+ * Remove dummy object from elm_naviframe.
Removals:
Modified: trunk/elementary/src/lib/elc_naviframe.c
===
--- trunk/elementary/src/lib/elc_naviframe.c2012-12-11 03:51:45 UTC
(rev 80627)
+++ trunk/elementary/src/lib/elc_naviframe.c2012-12-11 07:33:27 UTC
(rev 80628)
@@ -466,7 +466,6 @@
(sd-stack-last-prev, Elm_Naviframe_Item);
sd-stack = eina_inlist_remove(sd-stack, EINA_INLIST_GET(nit));
- if (!sd-stack) elm_widget_resize_object_set(WIDGET(it),
sd-dummy_edje);
if (top !sd-on_deletion) /* must raise another one */
{
@@ -1244,11 +1243,7 @@
_elm_naviframe_smart_add(Eo *obj, void *_pd, va_list *list EINA_UNUSED)
{
Elm_Naviframe_Smart_Data *priv = _pd;
- Elm_Widget_Smart_Data *wd = eo_data_get(obj, ELM_OBJ_WIDGET_CLASS);
- priv-dummy_edje = wd-resize_obj =
- edje_object_add(evas_object_evas_get(obj));
-
eo_do_super(obj, evas_obj_smart_add());
priv-auto_pushed = EINA_TRUE;
@@ -1304,8 +1299,6 @@
sd-on_deletion = EINA_FALSE;
- evas_object_del(sd-dummy_edje);
-
eo_do_super(obj, evas_obj_smart_del());
}
@@ -1587,7 +1580,6 @@
(sd-stack-last-prev, Elm_Naviframe_Item);
sd-stack = eina_inlist_remove(sd-stack, EINA_INLIST_GET(it));
- if (!sd-stack) elm_widget_resize_object_set(obj, sd-dummy_edje);
if (prev_it)
{
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Gustavo Lima Chaves
Senior Developer
ProFUSION embedded systems
http://profusion.mobi
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] my e is broken :(
This option was enabled by default (removed .e and start a new conf) Mmh, i found some old files of enlightenment installed in /opt, i removed them and now im unable to reproduce the problem (it should not conflict, but anyways) I will report it back if i see again the problem 2012/12/11 Carsten Haitzler ras...@rasterman.com disabled dont composite fullscreen windows ? -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Memory Leak in Eet + OpenSSL
Yes, now it works fine. Thx a lot! 2012/12/11 Cedric BAIL cedric.b...@free.fr Hello, On Tue, Dec 11, 2012 at 8:03 PM, Leandro Santiago leandrosansi...@gmail.com wrote: Hello again. I've tested that same example I sent with eet-1.7.3, released at Dec 7th and the leak still happens. I haven't tested the eet from trunk, because after you had moved many libraries to a single project (efl) it became a bit hard to build eet here (now I also have to have installed the dependencies of the other libraries which I don't use, like x-stuff, etc. :-( ). But I don't think this problem has been resolved in trunk, because when I got a diff between the file eet_cipher.c in 1.7.3 and in the trunk and there's no code related to that problem. Have anyone else ran in valgrind the code I sent to reproduce the bug or confirm if it's a bug in eet or openssl (or even in my code)? It should be fixed in svn (both trunk and branch). -- Cedric BAIL -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Sent from my Atari -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [Announce] Enlightenment DR 0.17 Gamma
This release of E17 is also known as The Hulk for obvious reasons. Changelog: * Translation updates * Clock and cpufreq gadgets now consume less cpu * Slider widget can no longer explode the stack * Backlight setting improved, now more reliable * mkstemps no longer used; portability++ * Really move option in filemanager renamed to something more descriptive * Resizable dialogs are now able to be maximized * Scrollbars now hide in more cases where they should * Dragging files to other applications from filemanager no longer causes file icon to disappear * Filemanager toolbar path items delete when corresponding path is removed * Mixer no longer causes a crash when pulseaudio is killed * Navigate menu no longer crashes when repeatedly navigating to a directory which has no listable contents * Tasks gadget no longer tries to delete its items repeatedly * Systray icon scaling improved * XDirectSave DND operations now work again * hicolor icon theme automatically applied now when no theme is selected * Fileselector no longer changes its entry text when changing directories * Filemanager New File action no longer creates file with garbage content * Don't composite fullscreen windows is now disabled by default * Notifications no longer do anything (including crash) when received during desklock * Gadgets module no longer crashes on unload and also correctly shows gadgets when loaded * Read-only entry widgets are now actually read-only * Filemanager no longer as hungry, saves some DND events for pager to enable drags on desktop pagers * Removed some potentially troublesome settings from advanced Composite settings * Systray now informs the user that it should not be placed on an invisible shelf * Window moving/resizing (and other mouse-related events) no longer behave strangely in the presence of autohiding shelves * Submenu item arrows now properly sized and aligned * [THEME] Lots of icons E17 GAMMA - 80662 http://download.enlightenment.org/releases/enlightenment-0.17.0-gamma.tar.gz http://download.enlightenment.org/releases/enlightenment-0.17.0-gamma.tar.bz2 -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Announce] Enlightenment DR 0.17 Gamma
On Tue, Dec 11, 2012 at 1:20 PM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: This release of E17 is also known as The Hulk for obvious reasons. The theme is now green?! -- Eduardo de Barros Lima ◤✠◢ ebl...@gmail.com -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: rui trunk/edbus
On Mon, 26 Nov 2012 11:57:49 -0200 Lucas De Marchi lucas.demar...@profusion.mobi wrote: Now tell me which distros would include a weekly (or so) updated EFL+e17? IMO it's better maintained by people that care about it I care about it, as probably do care other who build svn into rpms, and it doesn't hurt you. Following your advice would maybe make you happy, but hurt me. Is a neutral-win situation so undesirable you'd rather win an argument and make me loose more integration? yep, that's why I just sent an email instead of reverting the patch. Even if I don't like it. Also this is in edbus, not E. It's irrelevant, I'd need the dependencies built as RPMs and it's much better to have them built from the resulting make dist. , i.e. package maintainers. Since I don't have enough time to contribute with C code, at least I can contribute with a generic rpm spec that a released package can carry. Arch and gentoo have their own way to build *packages* from svn/git, without requiring you to change the build script. Doesn't RPM have such a thing? If one wants to have *more* work, not less, one can maintain it seperately. Doesn't seem smart, to me. What really bothers me is distributing a .spec. This demonstrates intent to support rpm, but not the others. No, it doesn't. What it shows is that there's an rpm user who cared about it. It's absolutely no statement on the others. And if it's not an intent, people start submitting patches to have their PKGBUILD, ebuild, whatever-build-their-distros to upstream projects. Also this rpm works in your distro, but not in another-random-distro-using-rpm. So *distributing* the spec may not hurt me, but it will for other people. I try to have it as agnostic as possible, also, I've seen no complaints, so there is no need for scarecrows. So, since you are building from unreleased svn/git, would it hurt you to at least not distribute the .spec? Why do you insist on wanting to make it useless? It doesn't hurt you, but all you propose hurts me (anything taking time away from me hurts me, including this surreal talk). Rui -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: rui trunk/edbus
On Tue, Dec 11, 2012 at 6:58 PM, Rui Miguel Silva Seabra r...@1407.org wrote: On Mon, 26 Nov 2012 11:57:49 -0200 Lucas De Marchi lucas.demar...@profusion.mobi wrote: Now tell me which distros would include a weekly (or so) updated EFL+e17? IMO it's better maintained by people that care about it I care about it, as probably do care other who build svn into rpms, and it doesn't hurt you. Following your advice would maybe make you happy, but hurt me. Is a neutral-win situation so undesirable you'd rather win an argument and make me loose more integration? yep, that's why I just sent an email instead of reverting the patch. Even if I don't like it. Also this is in edbus, not E. It's irrelevant, I'd need the dependencies built as RPMs and it's much better to have them built from the resulting make dist. , i.e. package maintainers. Since I don't have enough time to contribute with C code, at least I can contribute with a generic rpm spec that a released package can carry. Arch and gentoo have their own way to build *packages* from svn/git, without requiring you to change the build script. Doesn't RPM have such a thing? If one wants to have *more* work, not less, one can maintain it seperately. Doesn't seem smart, to me. What really bothers me is distributing a .spec. This demonstrates intent to support rpm, but not the others. No, it doesn't. What it shows is that there's an rpm user who cared about it. It's absolutely no statement on the others. And if it's not an intent, people start submitting patches to have their PKGBUILD, ebuild, whatever-build-their-distros to upstream projects. Also this rpm works in your distro, but not in another-random-distro-using-rpm. So *distributing* the spec may not hurt me, but it will for other people. I try to have it as agnostic as possible, also, I've seen no complaints, so there is no need for scarecrows. So, since you are building from unreleased svn/git, would it hurt you to at least not distribute the .spec? Why do you insist on wanting to make it useless? It doesn't hurt you, but all you propose hurts me (anything taking time away from me hurts me, including this surreal talk). ahn? Removing from EXTRA_DIST hurts you? It's useless for me and this type of thing is avoided in several projects I work with. But I won't argue anymore Keep it if you want. Lucas De Marchi -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: rui trunk/edbus
One user report from Korea: I got help from spec.in files in trunk while porting efl libraries to Tizen. Daniel Juyung Seo (SeoZ) On Wed, Dec 12, 2012 at 8:19 AM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: On Tue, Dec 11, 2012 at 6:58 PM, Rui Miguel Silva Seabra r...@1407.org wrote: On Mon, 26 Nov 2012 11:57:49 -0200 Lucas De Marchi lucas.demar...@profusion.mobi wrote: Now tell me which distros would include a weekly (or so) updated EFL+e17? IMO it's better maintained by people that care about it I care about it, as probably do care other who build svn into rpms, and it doesn't hurt you. Following your advice would maybe make you happy, but hurt me. Is a neutral-win situation so undesirable you'd rather win an argument and make me loose more integration? yep, that's why I just sent an email instead of reverting the patch. Even if I don't like it. Also this is in edbus, not E. It's irrelevant, I'd need the dependencies built as RPMs and it's much better to have them built from the resulting make dist. , i.e. package maintainers. Since I don't have enough time to contribute with C code, at least I can contribute with a generic rpm spec that a released package can carry. Arch and gentoo have their own way to build *packages* from svn/git, without requiring you to change the build script. Doesn't RPM have such a thing? If one wants to have *more* work, not less, one can maintain it seperately. Doesn't seem smart, to me. What really bothers me is distributing a .spec. This demonstrates intent to support rpm, but not the others. No, it doesn't. What it shows is that there's an rpm user who cared about it. It's absolutely no statement on the others. And if it's not an intent, people start submitting patches to have their PKGBUILD, ebuild, whatever-build-their-distros to upstream projects. Also this rpm works in your distro, but not in another-random-distro-using-rpm. So *distributing* the spec may not hurt me, but it will for other people. I try to have it as agnostic as possible, also, I've seen no complaints, so there is no need for scarecrows. So, since you are building from unreleased svn/git, would it hurt you to at least not distribute the .spec? Why do you insist on wanting to make it useless? It doesn't hurt you, but all you propose hurts me (anything taking time away from me hurts me, including this surreal talk). ahn? Removing from EXTRA_DIST hurts you? It's useless for me and this type of thing is avoided in several projects I work with. But I won't argue anymore Keep it if you want. Lucas De Marchi -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: rui trunk/edbus
On Tue, Dec 11, 2012 at 9:42 PM, Daniel Juyung Seo seojuyu...@gmail.com wrote:
One user report from Korea:
I got help from spec.in files in trunk while porting efl libraries to
Tizen.
One user report from Sealand:
I got help from put-here-the-build-script-file in
{fedora,suse,arch,put-here-your-distro-of-preference}'s package
repository while porting efl libraries to
{fedora,suse,arch,put-here-your-distro-of-preference}.
;-)
Lucas De Marchi
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo debug helper
Now this looks cool (except for the stopped at file... thing)! :) I don't quite understand your question about /opt/e17. If you just want to install it you just add it to Makefile.am like you would do any other data file (look at efl/data if you don't know how for some reason). The problem is that you probably don't want to install it to the same prefix as the efl, but actually to the gdb python dir, and you need to find a way to probe that. If that can't be probed, just install to the prefix, I guess it's good enough. -- Tom. On Tue, Dec 11, 2012 at 6:01 AM, daniel.za...@samsung.com daniel.za...@samsung.com wrote: Hey Tom, You are right. Don't tell me I know, I am always right! ;-) Following the script. Next step, how can I install it in /opt/e17? Which file do I need to modify? Script: class Eo_step(gdb.Command): def __init__(self): gdb.Command.__init__(self, eo_step, gdb.COMMAND_OBSCURE) def invoke (self, arg, from_tty): # While libeo is not reached, we step into while gdb.solib_name(gdb.selected_frame().pc()).find(libeo.so) == -1: # step by one assembly instruction, no print gdb.execute(stepi, False, to_string=True) # While we are in libeo or in an unknown function, we step into while (gdb.selected_frame().function() == None) or (gdb.solib_name(gdb.selected_frame().pc()).find(libeo.so) != -1): # step by one assembly instruction, no print gdb.execute(stepi, False, to_string=True) print Stopped at file + gdb.selected_frame().find_sal().symtab.filename+ line + str(gdb.selected_frame().find_sal().line) + function + str(gdb.selected_frame().function()) Eo_step() Daniel On 12/11/2012 01:20 AM, Tom Hacohen wrote: Hey Daniel, I found this in python.c in the gdb source tree: /* Implementation of gdb.solib_name (Long) - String. Returns the name of the shared library holding a given address, or None. */ static PyObject * gdbpy_solib_name (PyObject *self, PyObject *args) So just use gdb.solib_name... I just skimmed through the file, maybe there's more there I've missed, sounds like exactly what you are looking for. On Mon, Dec 10, 2012 at 9:18 AM, daniel.za...@samsung.com daniel.za...@samsung.com wrote: Hi Tom, 1. I will check it, maybe just print line and which file 2. I don't find how to get the library name. Sure it will be easier with the library. 3. I understand the point but for the moment I don't have a solution. I will investigate when time is with me (not so english, this sentence). If you find something on your side, tell me. Daniel On 12/10/2012 12:44 AM, Tom Hacohen wrote: Hey Daniel, Good thing that it works and I'm happy you improved it so fast, but I still have a couple of comments: 1. print You reached the function + str(gdb.selected_frame().function()) - It's probably better to change it to fit the gdb style of info messages better. It doesn't look like something you'd see out of gdb. 2. (yes I stay with that, it seems easier than with the library) - It just means you are doing something wrong as if you have a properly stripped binary there's no information about eo.c so it just won't work. Furthermore, I don't understand how it is easier, both are just a single test and it's a matter of just accessing a different property. 3. if (self.priv_current_line != self.priv_prev_line) or (str(self.priv_current_symtab) != str(self.priv_prev_symtab)): - If I understand it correctly it seems that you are looking until the line has changed. This isn't good because if for example you do: eo_do(obj, SET_A, get_some_number()) it'll fail as it'll get into the second function, and not the eo call. I don't know, maybe that's what you expect it to do, and then it's fine, but then the second loop kinda doesn't make sense... If you use the so name you can do something as simple as: 1. stepi until we get into libeo.so. 2. stepi until we get out of libeo.so. Very simple, very easy. No variables, state or anything. What do you think? -- Tom. On Sun, Dec 9, 2012 at 12:39 PM, daniel.za...@samsung.com daniel.za...@samsung.com wrote: Hi Tom, It works with stepi. The stepping process consists now in two phases: - stepping until we are no more in the the caller function - stepping while function name unknown or still in Eo.c (yes I stay with that, it seems easier than with the library) It now supports Eo with and without symbols. Code is following. Let's see soon in SVN. Daniel class Eo_step(gdb.Command): def __init__(self): gdb.Command.__init__(self, eo_step, gdb.COMMAND_OBSCURE) def invoke (self, arg, from_tty): self.priv_prev_line = gdb.selected_frame().find_sal().line self.priv_prev_symtab = gdb.selected_frame().find_sal().symtab while True: # step by one assembly instruction gdb.execute(stepi, False, to_string=True) # While
Re: [E-devel] E SVN: mello trunk/PROTO/elev8/src/bin
On Wed, Dec 12, 2012 at 2:09 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: elev8: Option to server mode do not daemonize. Summary: - Added option '--no-daemonize' to not start server mode as a daemon. Useful for systemd. Is the current daemon mode supported ? I tried it this weekend and the server did got nuts as soon as it started and consumed 100% CPU until I killed it. It was looking like some module initialization gone wrong. -- Cedric BAIL -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: mello trunk/PROTO/elev8/src/bin
On Tue, Dec 11, 2012 at 3:09 PM, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
elev8: Option to server mode do not daemonize.
Summary:
- Added option '--no-daemonize' to not start server mode as a daemon.
Useful for systemd.
Author:ederson eder...@profusion.mobi
Author: mello
Date: 2012-12-11 09:09:39 -0800 (Tue, 11 Dec 2012)
New Revision: 80674
Trac: http://trac.enlightenment.org/e/changeset/80674
Modified:
trunk/PROTO/elev8/src/bin/args.c trunk/PROTO/elev8/src/bin/args.h
trunk/PROTO/elev8/src/bin/main.cc
Modified: trunk/PROTO/elev8/src/bin/args.c
===
--- trunk/PROTO/elev8/src/bin/args.c2012-12-11 16:48:49 UTC (rev 80673)
+++ trunk/PROTO/elev8/src/bin/args.c2012-12-11 17:09:39 UTC (rev 80674)
@@ -17,6 +17,7 @@
{
ECORE_GETOPT_STORE_DEF_BOOL(0, debug, enable debuggind mode,
EINA_TRUE),
debugging?
ECORE_GETOPT_STORE_DEF_BOOL(0, server, enable server mode,
EINA_TRUE),
+ECORE_GETOPT_STORE_DEF_BOOL(0, no-daemonize, do not create a daemon
on server mode, EINA_TRUE),
ECORE_GETOPT_STORE_DEF_BOOL(0, shutdown, shutdown elev8 server.,
EINA_TRUE),
ECORE_GETOPT_STORE_DEF_BOOL(0, connect, run app spawing a elev8
server., EINA_TRUE),
ECORE_GETOPT_HELP('h', help),
@@ -33,6 +34,7 @@
Ecore_Getopt_Value values[] = {
ECORE_GETOPT_VALUE_BOOL(args-debug),
ECORE_GETOPT_VALUE_BOOL(args-server),
+ ECORE_GETOPT_VALUE_BOOL(args-no_daemonize),
ECORE_GETOPT_VALUE_BOOL(args-shutdown),
ECORE_GETOPT_VALUE_BOOL(args-connect),
ECORE_GETOPT_VALUE_BOOL(args-quit),
Modified: trunk/PROTO/elev8/src/bin/args.h
===
--- trunk/PROTO/elev8/src/bin/args.h2012-12-11 16:48:49 UTC (rev 80673)
+++ trunk/PROTO/elev8/src/bin/args.h2012-12-11 17:09:39 UTC (rev 80674)
@@ -11,6 +11,7 @@
typedef struct {
Eina_Bool debug;
Eina_Bool server;
+ Eina_Bool no_daemonize;
Eina_Bool shutdown;
Eina_Bool connect;
Eina_Bool quit;
Modified: trunk/PROTO/elev8/src/bin/main.cc
===
--- trunk/PROTO/elev8/src/bin/main.cc 2012-12-11 16:48:49 UTC (rev 80673)
+++ trunk/PROTO/elev8/src/bin/main.cc 2012-12-11 17:09:39 UTC (rev 80674)
@@ -493,7 +493,8 @@
if (args.server)
{
-daemonize();
+if (!args.no_daemonize)
+ daemonize();
why not just remove daemonize support? systemd and other inits can
handle the damonization part for themselves. No need for this.
Lucas De Marchi
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: e17 mild theme
On Tue, 11 Dec 2012 21:06:42 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Hi all, Attached is a mild.patch that applies to e17 and provides a simplified theme. Please also add the attached images to data/themes/img folder so the build works. The generated mild.edj is also attached for ease of test. Overall I did some quick hacks to evaluate how it would look, there are some inconsistencies and overall I'd like to have the icons without the glow and blue by default, which would take a major amount of work to get them from raster's originals. Some screenshots: - Shelf and gadgets: http://www.enlightenment.org/ss/e-50c7ba638fdb29.64242933.png - Config and Evry: http://enlightenment.org/~barbieri/config-and-evry.jpg Please let me know of your ideas regarding it. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 It's so mild!!! -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Announce] Enlightenment DR 0.17 Gamma
On 12/11/2012 11:59 PM, Eduardo Lima (Etrunko) wrote: On Tue, Dec 11, 2012 at 1:20 PM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: This release of E17 is also known as The Hulk for obvious reasons. The theme is now green?! I think he means that E17 is now officially bloated ;) -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
