Re: [E-devel] E SVN: raster trunk/efreet/src/lib
On Tue, Mar 30, 2010 at 7:15 AM, Enlightenment SVN
wrote:
> Log:
> comment++
>
>
> Author: raster
> Date: 2010-03-29 22:15:33 -0700 (Mon, 29 Mar 2010)
> New Revision: 47577
>
> Modified:
> trunk/efreet/src/lib/efreet_desktop.c
>
> Modified: trunk/efreet/src/lib/efreet_desktop.c
> ===
> --- trunk/efreet/src/lib/efreet_desktop.c 2010-03-30 05:03:57 UTC (rev
> 47576)
> +++ trunk/efreet/src/lib/efreet_desktop.c 2010-03-30 05:15:33 UTC (rev
> 47577)
> @@ -745,6 +745,10 @@
> eina_list_free(desktop->categories);
> eina_list_free(desktop->mime_types);
> IF_FREE_HASH(desktop->x);
> + // FIXME: loaded from eet. eet data descriptior is the default eina
> + // setup that means all strings are "eina_stringshare_add()"ed. this
> + // means we need to eina_stringshare_del() them here - until this is
> + // no longer the case (they are directly mmaped)
> }
> else
> {
>
I don't understand this comment. Efreet code seems to correctly use
eet_eina_file_data_descriptor_class_set that correctly setup callback
to directly use mmaped string. So why are you referring to stringshare
?
--
Cedric BAIL
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/efreet/src/lib
On Tue, 30 Mar 2010 13:28:38 +0200 Cedric BAIL said:
> On Tue, Mar 30, 2010 at 7:15 AM, Enlightenment SVN
> wrote:
> > Log:
> > comment++
> >
> >
> > Author: raster
> > Date: 2010-03-29 22:15:33 -0700 (Mon, 29 Mar 2010)
> > New Revision: 47577
> >
> > Modified:
> > trunk/efreet/src/lib/efreet_desktop.c
> >
> > Modified: trunk/efreet/src/lib/efreet_desktop.c
> > ===
> > --- trunk/efreet/src/lib/efreet_desktop.c 2010-03-30 05:03:57 UTC
> > (rev 47576) +++ trunk/efreet/src/lib/efreet_desktop.c 2010-03-30
> > 05:15:33 UTC (rev 47577) @@ -745,6 +745,10 @@
> > eina_list_free(desktop->categories);
> > eina_list_free(desktop->mime_types);
> > IF_FREE_HASH(desktop->x);
> > + // FIXME: loaded from eet. eet data descriptior is the default eina
> > + // setup that means all strings are "eina_stringshare_add()"ed. this
> > + // means we need to eina_stringshare_del() them here - until this is
> > + // no longer the case (they are directly mmaped)
> > }
> > else
> > {
> >
>
> I don't understand this comment. Efreet code seems to correctly use
> eet_eina_file_data_descriptor_class_set that correctly setup callback
> to directly use mmaped string. So why are you referring to stringshare
> ?
oooh oops oops. i was looking at eet_eina_stream_data_descriptor_class_set()
> --
> Cedric BAIL
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> 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
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Edje colors
Hi, I have a question regarding the color sent to the evas engine when drawing a rectangle in the context. When I use evas to create the rectangle the color in the context is the same as the color I sent to evas_object_color_set. When I am using edje the color seems to be premultiplied when the object is not opaque. (I do not have any clip objects, as far as I know). Why could this be? Is it correct that the common engine in evas assumes the color is premultiplied when for example drawing a rectangle with evas_common_rectangle_draw? How and when is the color modified on its way from the edc file to the context color during rectangle_draw in the engine when drawing a rectangle? I'm using a rather old revision of the efl libraries and it would be very difficult for me to upgrade so if anyone knows if this is a bug that has been fixed in the past year or so it would be very appriciated. /Mikael -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje colors
On Tue, Mar 30, 2010 at 4:20 PM, Mikael Liljeroth wrote: > Hi, I have a question regarding the color sent to the evas engine when > drawing a rectangle in the context. > When I use evas to create the rectangle the color in the context is the same > as the color I sent to evas_object_color_set. > When I am using edje the color seems to be premultiplied when the object is > not opaque. > (I do not have any clip objects, as far as I know). Why could this be? Because evas expect color to be premultiplied every where and edje ease your job by premultiplying them before calling evas. > Is it correct that the common engine in evas assumes the color is > premultiplied when for example drawing a rectangle with > evas_common_rectangle_draw? Yes. > How and when is the color modified on its way from the edc file to the > context color during rectangle_draw in the engine when drawing a rectangle? Color are premultiplied in edje/src/lib/edje_calc.c at line 1954. > I'm using a rather old revision of the efl libraries and it would be very > difficult for me to upgrade so if anyone knows if this is a bug that > has been fixed in the past year or so it would be very appriciated. -- Cedric BAIL -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: manowarrior trunk/e/data/themes/images
On Sat, Mar 27, 2010 at 1:49 PM, Enlightenment SVN wrote: > Log: > new folder icon, hope you like it. I like it, but could you send a high resolution picture? I often use 128 or 256 size for my ~/Pictures and the folder looks ugly scaled to that size. As folder is very, very common icon, maybe it is worth to define the Edje group to be smart and select the correct image file based on the group geometry (see default.edc, bluez and connman disable some UI elements based on the edje group view size). So we can have different formats like 24x24, 48x48, 128x128, 256x256 and choose between them. Maybe 24x24 (or similar, used by menu) could use a different icon, as the current looks almost indistinguishable at that size. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Broken elm_anchorblocks ?
(gdb) bt #0 0x003fb8e79d4c in free () from /lib64/libc.so.6 #1 0x00362d0420c5 in _evas_object_table_calculate_layout_regular (o=) at evas_object_table.c:804 #2 _evas_object_table_smart_calculate_regular (o=) at evas_object_table.c:812 #3 _evas_object_table_smart_calculate (o=) at evas_object_table.c:885 #4 0x00362d03a8d8 in evas_call_smarts_calculate (e=0x6973d0) at evas_object_smart.c:831 #5 0x00362d057d71 in evas_render_updates_internal (e=0x6973d0, make_updates=1 '\001', do_draw=) at evas_render.c:801 #6 0x00363000ec40 in _ecore_evas_x_render () from /usr/lib64/libecore_evas-ver-pre-svn-05.so.0 #7 0x003630008d44 in _ecore_evas_idle_enter () from /usr/lib64/libecore_evas-ver-pre-svn-05.so.0 #8 0x00362c80ad74 in _ecore_idle_enterer_call () from /usr/lib64/libecore-ver-pre-svn-05.so.0 #9 0x00362c80c65e in _ecore_main_loop_iterate_internal () from /usr/lib64/libecore-ver-pre-svn-05.so.0 #10 0x00362c80b6ab in ecore_main_loop_begin () from /usr/lib64/libecore-ver-pre-svn-05.so.0 #11 0x0040cf0e in elm_main (argc=7591968, argv=0x6e79c0) at elmdentica.c:1403 #12 0x003fb8e1eb1d in __libc_start_main () from /lib64/libc.so.6 #13 0x00404869 in _start () (gdb) bt full #0 0x003fb8e79d4c in free () from /lib64/libc.so.6 No symbol table info available. #1 0x00362d0420c5 in _evas_object_table_calculate_layout_regular (o=) at evas_object_table.c:804 cols = 0x87fee0 w = 224 opt = rows = 0x720938 x = 38 h = 133 c = l = y = 178 #2 _evas_object_table_smart_calculate_regular (o=) at evas_object_table.c:812 No locals. #3 _evas_object_table_smart_calculate (o=) at evas_object_table.c:885 priv = __FUNCTION__ = "_evas_object_table_smart_calculate" #4 0x00362d03a8d8 in evas_call_smarts_calculate (e=0x6973d0) at evas_object_smart.c:831 obj = o = calculate = 0x3fb9174ff0 i = #5 0x00362d057d71 in evas_render_updates_internal (e=0x6973d0, make_updates=1 '\001', do_draw=) at evas_render.c:801 updates = 0x0 ll = surface = alpha = r = ux = uy = uw = uh = cx = cy = cw = ch = i = j = haveup = 0 __FUNCTION__ = "evas_render_updates_internal" #6 0x00363000ec40 in _ecore_evas_x_render () from /usr/lib64/libecore_evas-ver-pre-svn-05.so.0 No symbol table info available. #7 0x003630008d44 in _ecore_evas_idle_enter () from /usr/lib64/libecore_evas-ver-pre-svn-05.so.0 No symbol table info available. #8 0x00362c80ad74 in _ecore_idle_enterer_call () from /usr/lib64/libecore-ver-pre-svn-05.so.0 No symbol table info available. #9 0x00362c80c65e in _ecore_main_loop_iterate_internal () from /usr/lib64/libecore-ver-pre-svn-05.so.0 No symbol table info available. #10 0x00362c80b6ab in ecore_main_loop_begin () from /usr/lib64/libecore-ver-pre-svn-05.so.0 No symbol table info available. #11 0x0040cf0e in elm_main (argc=7591968, argv=0x6e79c0) at elmdentica.c:1403 bg = box = 0x6e79c0 toolbar = 0x6e7db0 ---Type to continue, or q to quit--- bt = icon = 0x7283e0 box2 = 0x73d820 hoversel = #12 0x003fb8e1eb1d in __libc_start_main () from /lib64/libc.so.6 No symbol table info available. #13 0x00404869 in _start () No symbol table info available. (gdb) Em 29-03-2010 01:27, Carsten Haitzler (The Rasterman) escreveu: > On Sun, 28 Mar 2010 20:28:14 +0100 Rui Miguel Silva Seabra > said: > > gdb debugging pls. :) reproduction case pls (preference for this is a patch to > elementary_test to have that case there so in future we have a test suite for > it and can make sure it works). :) > >> Hi, >> >> I'm adding support in elmdentica for actions on @users !groups, #tags >> etc... that come up on identi.ca/twitter messages. >> >> However it seems I have detected a problem with elm_anchorblocks... >> >> All anchors are being properly detected BUT some don't run the clicked >> handler (even though they get a shadow). BTW, shouldn't this shadow >> disappear automatically? It doesn't, right now... >> >> >> Some work as planned. >> >> Some blow up like this: >> Program received signal SIGSEGV, Segmentation fault. >> (gdb) bt >> #0 0x003fb8e79d4c in free () from /lib64/libc.so.6 >> #1 0x76e1a0c5 in ?? () from /usr/lib64/libevas-ver-pre-svn-05.so.0 >> #2 0x76e128d8 in evas_call_smarts_calculate () from >> /usr/lib64/libevas-ver-pre-svn-05.so.0 >> #3 0x76e2fd71 in ?? () from /usr/lib64/libevas-ver-pre-svn-05.so.0 >> #4 0x77b67c40 in ?? () from >> /usr/lib64/libecore_evas-ver-pre-svn-05.so.0 >> #5 0x77b61d44 in ?? () from >> /usr/lib64/libecore_evas-ver-pre-svn-05.so.0 >> #6 0x75505d74 in _ecore_idle_enterer_call () from >> /usr/lib64/libecore-ver-pre-svn-05.
[E-devel] Include hour and minute in rpm spec release tags
Hi, Most (if not all) rpm specs define the following: Release: 0.%(date '+%Y%m%d') I propose to change this to: Release: 0.%(date '+%Y%m%d%H%M') The reasoning is: * I like to install in rpms compiled from trunk * rpms provide a nice and cleaner build environment with dep management * if one is working on a library and installing it frequently, just %Y%m%d isn't enough Since I have done this on some specs, unless anyone strongly opposes this change, I plan to do it during easter. Nothing should break, but this heads-up should be particularly important to someone with a build host, or something, which is rpm based. What do you think? Rui -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] e17 issue: EDJE not finding LUA on MacOS-X Leopard
My environment is MacOS-X 10.5.8 (Leopard) on a Macbook Pro (64-bit Intel i686 Darwin), gcc 4.0.1 from XCode 3.1.4. I am not using fink, everything installs in /usr/local. e16 and many other X11 programs install successfully. $LD_LIBRARY_PATH=/lib:/usr/lib:/usr/X11/lib:/usr/local/lib The current release of EDJE fails to compile on MacOSX due to an issue between EDJE and LUA. This prevents completion of prerequisites for e17. On MacOSX the LUA distribution installs perfectly except it does library linkage differently than EDJE expects. This causes EDJE to fail with an error that LUA is not installed, when in fact it is. The LUA source does not have a configure script and is compiled by non- standard makefile arguments. They are fairly simple and clearly explained in the README. On MacOSX the make command is "sudo make macosx install" followed by "sudo make ranlib". This is roughly equivalent to "make; sudo make install; sudo ranlib /usr/local/lib/ liblua.a". However the LUA compilation does not produce .so libraries or .pc files. It produces the .a library and working binaries. "make test" is successful. pkg-config does not see it. "pkg-config --list-all | grep lua" produces nothing. When I try to compile EDJE I get the following error: ... checking pkg-config is at least version 0.9.0... yes checking for LUA... no checking for LUA... no checking for LUA... no checking for LUA... no configure: error: unable to find Lua If LUA produced a .pc file, I could manually move that from lua's src directory to /usr/lib/pkgconfig. That would be one possible fix but it requires mods to the lua source. Alternatively EDJE could look for $LD_LIBRARY_PATH/liblua.a instead of whatever it is doing. I'm not an expert but it seems it shouldn't be too hard to make a diff to fix this, but is a little beyond my skills. Has anyone looked at this? Dave -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 issue: EDJE not finding LUA on MacOS-X Leopard
On Tue, 30 Mar 2010, Dave Ray wrote: > My environment is MacOS-X 10.5.8 (Leopard) on a Macbook Pro (64-bit > Intel i686 Darwin), gcc 4.0.1 from XCode 3.1.4. > I am not using fink, everything installs in /usr/local. e16 and many > other X11 programs install successfully. > $LD_LIBRARY_PATH=/lib:/usr/lib:/usr/X11/lib:/usr/local/lib > > The current release of EDJE fails to compile on MacOSX due to an issue > between EDJE and LUA. This prevents completion of prerequisites for > e17. On MacOSX the LUA distribution installs perfectly except it does > library linkage differently than EDJE expects. This causes EDJE to > fail with an error that LUA is not installed, when in fact it is. > > The LUA source does not have a configure script and is compiled by non- > standard makefile arguments. They are fairly simple and clearly > explained in the README. On MacOSX the make command is "sudo make > macosx install" followed by "sudo make ranlib". This is roughly > equivalent to "make; sudo make install; sudo ranlib /usr/local/lib/ > liblua.a". However the LUA compilation does not produce .so libraries > or .pc files. It produces the .a library and working binaries. "make > test" is successful. > > pkg-config does not see it. > "pkg-config --list-all | grep lua" produces nothing. > > When I try to compile EDJE I get the following error: > ... > checking pkg-config is at least version 0.9.0... yes > checking for LUA... no > checking for LUA... no > checking for LUA... no > checking for LUA... no > configure: error: unable to find Lua > > If LUA produced a .pc file, I could manually move that from lua's src > directory to /usr/lib/pkgconfig. That would be one possible fix but it > requires mods to the lua source. > > Alternatively EDJE could look for $LD_LIBRARY_PATH/liblua.a instead of > whatever it is doing. > > I'm not an expert but it seems it shouldn't be too hard to make a diff > to fix this, but is a little beyond my skills. > > Has anyone looked at this? Yes, I have. The problem is not compatibility between edje and lua. The problem is that there is no .pc file in the lua source. These stupid developpers answered me that they want to reduce the number of files in their tarball when i asked why there is no .pc file. Do you believe it ?? On linux distro, package maintainers usually add a .pc file. Well, there is several solutions: 1) as you said, write your own .pc file and put it in the correct directory. (that's what i do for Windows) 2) i can add a check of lua library in edje's configure.ac if no .pc file is found. I'll try to find some time to improve lua check this week best regards -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
