Re: [E-devel] E SVN: discomfitor IN trunk/evas: . src/modules/engines/gl_x11
On Mon, Mar 7, 2011 at 6:41 AM, Enlightenment SVN
wrote:
> Log:
> fix weird segv I found when trying opengl mode in comp module on my desktop,
> waiting for someone to give me the "good job you did it correctly" before I
> backport since I probably didn't
Just reading the patch, seems like you added GLU as a dependency
without checking for it before ? Does evas already rely on GLU ?
> Author: discomfitor
> Date: 2011-03-06 21:41:49 -0800 (Sun, 06 Mar 2011)
> New Revision: 57546
> Trac: http://trac.enlightenment.org/e/changeset/57546
>
> Modified:
> trunk/evas/ChangeLog trunk/evas/src/modules/engines/gl_x11/evas_engine.h
> trunk/evas/src/modules/engines/gl_x11/evas_x_main.c
>
> Modified: trunk/evas/ChangeLog
> ===
> --- trunk/evas/ChangeLog 2011-03-06 23:28:37 UTC (rev 57545)
> +++ trunk/evas/ChangeLog 2011-03-07 05:41:49 UTC (rev 57546)
> @@ -135,3 +135,8 @@
> 2011-02-27 Vincent Torri
>
> * Fixed static linking of the bmp, wbmp and tga loaders
> +
> +2011-03-07 Mike Blumenkrantz
> +
> + * Fix segv when trying to set gl viewpoint with NULL ctx
> + * Add more verbose error message when glXMakeCurrent fails
>
> Modified: trunk/evas/src/modules/engines/gl_x11/evas_engine.h
> ===
> --- trunk/evas/src/modules/engines/gl_x11/evas_engine.h 2011-03-06 23:28:37
> UTC (rev 57545)
> +++ trunk/evas/src/modules/engines/gl_x11/evas_engine.h 2011-03-07 05:41:49
> UTC (rev 57546)
> @@ -24,7 +24,7 @@
> # include
> # include
> # include // xres - dpi
> -#endif
> +# endif
> # else
> # include
> # include
> @@ -32,6 +32,7 @@
> # include
> # include // xres - dpi
> # include
> +# include
> # include
> # include
> # endif
>
> Modified: trunk/evas/src/modules/engines/gl_x11/evas_x_main.c
> ===
> --- trunk/evas/src/modules/engines/gl_x11/evas_x_main.c 2011-03-06 23:28:37
> UTC (rev 57545)
> +++ trunk/evas/src/modules/engines/gl_x11/evas_x_main.c 2011-03-07 05:41:49
> UTC (rev 57546)
> @@ -300,7 +300,7 @@
> {
> if (!glXMakeCurrent(gw->disp, gw->win, gw->context))
> {
> - printf("Error: glXMakeCurrent(%p, 0x%x, %p) failed\n",
> (void *)gw->disp, (unsigned int)gw->win, (void *)gw->context);
> + printf("Error: glXMakeCurrent(%p, 0x%x, %p) failed -
> '%s'\n", (void *)gw->disp, (unsigned int)gw->win, (void *)gw->context,
> gluErrorString(glGetError()));
> eng_window_free(gw);
> return NULL;
> }
> @@ -531,7 +531,7 @@
> #endif
> }
> }
> - if (gw) evas_gl_common_context_use(gw->gl_context);
> + if (gw && gw->gl_context) evas_gl_common_context_use(gw->gl_context);
> }
>
> void
>
>
> --
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
>
--
Cedric BAIL
--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [RFC] Evas - OpenGL and Evas (Part 3)
Hi all,
In my earlier post, I've discussed about the issues with getting the
evas_object_image_native_surface_set(..., Evas_Native_Surface *surf);
function for setting OpenGL output texture. There was also a disucssion
about how Evas should provide a GL glue layer. We've discussed two
proposals.
After some discussion, I went ahead with the preferred way and have
implemented the APIs.
The APIs go something like... (in Evas_GL.h)
EAPI Evas_GL *evas_gl_new (Evas *e);
EAPI Evas_GL_Surface*evas_gl_surface_create (Evas_GL *evas_gl,
Evas_GL_Config *cfg, int w, int h);
EAPI Evas_GL_Context*evas_gl_context_create (Evas_GL *evas_gl,
Evas_GL_Context *share_ctx);
EAPI Eina_Bool evas_gl_make_current(Evas_GL
*evas_gl, Evas_GL_Surface *surf, Evas_GL_Context *ctx);
EAPI Evas_GL_Func evas_gl_proc_address_get (Evas_GL *evas_gl,
const char *name);
EAPI Eina_Bool evas_gl_native_surface_get (Evas_GL
*evas_gl, Evas_GL_Surface *surf, Evas_Native_Surface *ns);
I actually have the above APIs running on my machine but
instead of dumping the entire thing, I wanted to get incremental comments
for review.
I'm now attaching Evas_GL.h and evas_gl.c and a Sample program that uses the
APIs.
Your comments would be very much appreciated. After the initial review,
I'll submit
a RFC for the engine part of the code that I wrote for gl_x11 module.
One issue that I ran into with the above APIs is that Evas_GL_Context is
already used
by the gl_common part of the code in the engine module. Upon discussing it
with Raster,
the consensus was that it was better to change the internal code since it's
not exposed.
So, in my implementation, I've changed the internal part to
Evas_Engine_GL_Context.
I just wanted to mention that here for now even though it won't show in the
files that i'm
attaching.
thanks!
Sung
#ifndef _EVAS_GL_H
#define _EVAS_GL_H
#include
#ifdef __cplusplus
extern "C" {
#endif
typedef struct _Evas_GL Evas_GL;
typedef struct _Evas_GL_Surface Evas_GL_Surface;
typedef struct _Evas_GL_Context Evas_GL_Context;
typedef struct _Evas_GL_ConfigEvas_GL_Config;
typedef void* Evas_GL_Func;
typedef enum _Evas_GL_Color_Format
{
EVAS_GL_RGB_8, // 8 bits per channel
EVAS_GL_RGBA_8,
EVAS_GL_RGB_32, // 32-bits per channel
EVAS_GL_RGBA_32,
} Evas_GL_Color_Format;
typedef enum _Evas_GL_Depth_Bits
{
EVAS_GL_DEPTH_BIT_8,
EVAS_GL_DEPTH_BIT_16,
EVAS_GL_DEPTH_BIT_24,
EVAS_GL_DEPTH_BIT_32,
EVAS_GL_DEPTH_NONE
} Evas_GL_Depth_Bits;
typedef enum _Evas_GL_Stencil_Bits
{
EVAS_GL_STENCIL_BIT_1,
EVAS_GL_STENCIL_BIT_2,
EVAS_GL_STENCIL_BIT_4,
EVAS_GL_STENCIL_BIT_8,
EVAS_GL_STENCIL_BIT_16,
EVAS_GL_STENCIL_NONE
} Evas_GL_Stencil_Bits;
struct _Evas_GL_Config
{
Evas_GL_Color_Format color_format;
Evas_GL_Depth_Bits depth_bits;
Evas_GL_Stencil_Bits stencil_bits;
};
/**
* @defgroup Evas_GL group for rendering GL on Evas
*
* Functions that are used to do GL rendering on Evas.
*
* @ingroup Evas_Canvas
*/
EAPI Evas_GL *evas_gl_new(Evas *e);
EAPI void evas_gl_free (Evas_GL *evas_gl);
EAPI Evas_GL_Surface *evas_gl_surface_create (Evas_GL *evas_gl, Evas_GL_Config *cfg, int w, int h);
EAPI void evas_gl_surface_destroy(Evas_GL *evas_gl, Evas_GL_Surface *surf);
EAPI Evas_GL_Context *evas_gl_context_create (Evas_GL *evas_gl, Evas_GL_Context *share_ctx);
EAPI void evas_gl_context_destroy(Evas_GL *evas_gl, Evas_GL_Context *ctx);
EAPI Eina_Boolevas_gl_make_current (Evas_GL *evas_gl, Evas_GL_Surface *surf, Evas_GL_Context *ctx);
EAPI Evas_GL_Func evas_gl_proc_address_get (Evas_GL *evas_gl, const char *name);
EAPI Eina_Boolevas_gl_native_surface_get (Evas_GL *evas_gl, Evas_GL_Surface *surf, Evas_Native_Surface *ns);
// EAPI Evas_GL *evas_gl_api_get(Evas *e, Evas_GL_API *glapi) EINA_ARG_NONNULL(1, 2);
#ifdef __cplusplus
}
#endif
#endif
#include "evas_common.h"
#include "evas_private.h"
#include "Evas_GL.h"
struct _Evas_GL
{
int magic;
Evas*evas;
};
struct _Evas_GL_Context
{
void*data;
};
struct _Evas_GL_Surface
{
void*data;
};
/**
* @addtogroup Evas_GL
* @{
*/
/**
* Creates a new Evas_GL object and returns a handle for gl rendering on efl.
*
* @param e The given evas.
* @return The created evas_gl object.
*/
EAPI Evas_GL *
evas_gl_new(Evas *e)
{
Evas_GL *evas_gl;
evas_gl = calloc(1, sizeof(Evas_GL));
if (!evas_gl) return NULL;
evas_gl->magic = MAGIC_EVAS_GL;
evas_gl->evas = e;
return evas_gl;
}
/**
* Frees the created Evas_GL object.
*
* @param evas_gl The given Evas_G
Re: [E-devel] E SVN: discomfitor IN trunk/evas: . src/modules/engines/gl_x11
On Mon, 7 Mar 2011, Cedric BAIL wrote:
On Mon, Mar 7, 2011 at 6:41 AM, Enlightenment SVN
wrote:
Log:
fix weird segv I found when trying opengl mode in comp module on my desktop, waiting for
someone to give me the "good job you did it correctly" before I backport since
I probably didn't
Just reading the patch, seems like you added GLU as a dependency
without checking for it before ? Does evas already rely on GLU ?
glu is not checked. But first, why is glu needed (that is, which functions
are part of its API) ?
Vincent
Author: discomfitor
Date: 2011-03-06 21:41:49 -0800 (Sun, 06 Mar 2011)
New Revision: 57546
Trac: http://trac.enlightenment.org/e/changeset/57546
Modified:
trunk/evas/ChangeLog trunk/evas/src/modules/engines/gl_x11/evas_engine.h
trunk/evas/src/modules/engines/gl_x11/evas_x_main.c
Modified: trunk/evas/ChangeLog
===
--- trunk/evas/ChangeLog 2011-03-06 23:28:37 UTC (rev 57545)
+++ trunk/evas/ChangeLog 2011-03-07 05:41:49 UTC (rev 57546)
@@ -135,3 +135,8 @@
2011-02-27 Vincent Torri
* Fixed static linking of the bmp, wbmp and tga loaders
+
+2011-03-07 Mike Blumenkrantz
+
+ * Fix segv when trying to set gl viewpoint with NULL ctx
+ * Add more verbose error message when glXMakeCurrent fails
Modified: trunk/evas/src/modules/engines/gl_x11/evas_engine.h
===
--- trunk/evas/src/modules/engines/gl_x11/evas_engine.h 2011-03-06 23:28:37 UTC
(rev 57545)
+++ trunk/evas/src/modules/engines/gl_x11/evas_engine.h 2011-03-07 05:41:49 UTC
(rev 57546)
@@ -24,7 +24,7 @@
# include
# include
# include // xres - dpi
-#endif
+# endif
# else
# include
# include
@@ -32,6 +32,7 @@
# include
# include // xres - dpi
# include
+# include
# include
# include
# endif
Modified: trunk/evas/src/modules/engines/gl_x11/evas_x_main.c
===
--- trunk/evas/src/modules/engines/gl_x11/evas_x_main.c 2011-03-06 23:28:37 UTC
(rev 57545)
+++ trunk/evas/src/modules/engines/gl_x11/evas_x_main.c 2011-03-07 05:41:49 UTC
(rev 57546)
@@ -300,7 +300,7 @@
{
if (!glXMakeCurrent(gw->disp, gw->win, gw->context))
{
- printf("Error: glXMakeCurrent(%p, 0x%x, %p) failed\n", (void
*)gw->disp, (unsigned int)gw->win, (void *)gw->context);
+ printf("Error: glXMakeCurrent(%p, 0x%x, %p) failed - '%s'\n", (void
*)gw->disp, (unsigned int)gw->win, (void *)gw->context, gluErrorString(glGetError()));
eng_window_free(gw);
return NULL;
}
@@ -531,7 +531,7 @@
#endif
}
}
- if (gw) evas_gl_common_context_use(gw->gl_context);
+ if (gw && gw->gl_context) evas_gl_common_context_use(gw->gl_context);
}
void
--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Cedric BAIL
--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: discomfitor IN trunk/evas: . src/modules/engines/gl_x11
On Mon, 7 Mar 2011, Vincent Torri wrote:
On Mon, 7 Mar 2011, Cedric BAIL wrote:
On Mon, Mar 7, 2011 at 6:41 AM, Enlightenment SVN
wrote:
Log:
fix weird segv I found when trying opengl mode in comp module on my
desktop, waiting for someone to give me the "good job you did it
correctly" before I backport since I probably didn't
Just reading the patch, seems like you added GLU as a dependency
without checking for it before ? Does evas already rely on GLU ?
glu is not checked. But first, why is glu needed (that is, which functions
used in evas, of course
Vincent
are part of its API) ?
Vincent
Author: discomfitor
Date: 2011-03-06 21:41:49 -0800 (Sun, 06 Mar 2011)
New Revision: 57546
Trac: http://trac.enlightenment.org/e/changeset/57546
Modified:
trunk/evas/ChangeLog trunk/evas/src/modules/engines/gl_x11/evas_engine.h
trunk/evas/src/modules/engines/gl_x11/evas_x_main.c
Modified: trunk/evas/ChangeLog
===
--- trunk/evas/ChangeLog 2011-03-06 23:28:37 UTC (rev 57545)
+++ trunk/evas/ChangeLog 2011-03-07 05:41:49 UTC (rev 57546)
@@ -135,3 +135,8 @@
2011-02-27 Vincent Torri
* Fixed static linking of the bmp, wbmp and tga loaders
+
+2011-03-07 Mike Blumenkrantz
+
+ * Fix segv when trying to set gl viewpoint with NULL ctx
+ * Add more verbose error message when glXMakeCurrent fails
Modified: trunk/evas/src/modules/engines/gl_x11/evas_engine.h
===
--- trunk/evas/src/modules/engines/gl_x11/evas_engine.h 2011-03-06
23:28:37 UTC (rev 57545)
+++ trunk/evas/src/modules/engines/gl_x11/evas_engine.h 2011-03-07
05:41:49 UTC (rev 57546)
@@ -24,7 +24,7 @@
# include
# include
# include // xres - dpi
-#endif
+# endif
# else
# include
# include
@@ -32,6 +32,7 @@
# include
# include // xres - dpi
# include
+# include
# include
# include
# endif
Modified: trunk/evas/src/modules/engines/gl_x11/evas_x_main.c
===
--- trunk/evas/src/modules/engines/gl_x11/evas_x_main.c 2011-03-06
23:28:37 UTC (rev 57545)
+++ trunk/evas/src/modules/engines/gl_x11/evas_x_main.c 2011-03-07
05:41:49 UTC (rev 57546)
@@ -300,7 +300,7 @@
{
if (!glXMakeCurrent(gw->disp, gw->win, gw->context))
{
- printf("Error: glXMakeCurrent(%p, 0x%x, %p) failed\n",
(void *)gw->disp, (unsigned int)gw->win, (void *)gw->context);
+ printf("Error: glXMakeCurrent(%p, 0x%x, %p) failed -
'%s'\n", (void *)gw->disp, (unsigned int)gw->win, (void *)gw->context,
gluErrorString(glGetError()));
eng_window_free(gw);
return NULL;
}
@@ -531,7 +531,7 @@
#endif
}
}
- if (gw) evas_gl_common_context_use(gw->gl_context);
+ if (gw && gw->gl_context) evas_gl_common_context_use(gw->gl_context);
}
void
--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Cedric BAIL
--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [Patch] elm_smart_scroller_child_region_show_internal
Dear all In the els_scroller of the elementary, the function "elm_smart_scroller_child_region_show_internal" have a problem. If the parameters "x,y,w,h" have the wrong value like "elm_scroller_region_show(scroller, -300, -300, 900, 900);", the scroller move the position temporarily. The scroller seem to jump. So if the value of the parameter is not valid, it should be changed to valid value. The work is applied already in the function "elm_smart_scroller_region_bring_in". It should be applied in the function "elm_smart_scroller_child_region_show_internal" too. I changed the code like bring_in function. Please find the attached patch file. Thanks, Jaehwan Kim. scroller.patch Description: Binary data -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Google Summer of Code 2011 Application....
On Fri, 4 Mar 2011 09:04:13 +0100 (CET) Vincent Torri said: > > > On Fri, 4 Mar 2011, Andrey Riabushenko wrote: > > > As I an extra idea for GSoc2010: support for wayland. Mentors? > > raster had an opinion about Wayland and the EFL. I can't remember exactly > what he wanted. You should ask him directly, or write a new thread with an > explicit subject, otherwise he can miss it (it seems he has a lot of > mails). i don't have time to mentor - but let me just say this - to do wayland support you are firstly taking on support for a display system that is very immature and VERY hard to develop for or even get up and running, secondly - you'd better know what you are doing to do it, third - it, like all display systems that have come before it to try and "beat x11", has a high probability of failure. nothing has beaten x to date. fourth - if you were to do it - i'd expect not just implementation of display AND input (evas + ecore), but i'd also expect an implementation of a wayland display SERVER using EFL. that basically means making a wayland window manager+compositor using EFL. > > Ravenlock ÿÿ: > > > >> All, > >> > >> We have officially submitted our application to become a Mentoring > >> Organization for the Google Summer of Code 2011. > >> > >> We are very hopeful of its acceptance. We have a nice pool of eager > >> mentors as well as an ideas page that is growing daily. Our ideas > >> page can be found here: > >> > >>http://trac.enlightenment.org/e/wiki/GSoC_2011_Project_Ideas > >> > >> If you are an interested student, please take a look. Feel free to > >> e-mail the mailing lists with ideas for discussion, or to jump into > >> IRC. We can be reached in #e on chat.freenode.net > >> > > > > > > -- > > What You Don't Know About Data Connectivity CAN Hurt You > > This paper provides an overview of data connectivity, details > > its effect on application quality, and explores various alternative > > solutions. http://p.sf.net/sfu/progress-d2d > > ___ > > 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 -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] Receipe website
On Sun, Mar 6, 2011 at 21:30, Alex-P. Natsios wrote: > why use websvn ? > will there be a new exclusive/separate svn repo/serve on e4? > and if so why use another external websvn browser, when there already > is a trac/svn browser on e.org? > > to get the live status of commits in a repository a whole browser is > pointless and doesn't actually do quite the work you want it to. > svn has hooks that can be used for that sort of thing. > A CIA/post-commit hook can be written for automatically puling the > commits "real-time" in the recipe website like it is already being > done on E-SVN ML > > about github now since for most if not all things svn is used i guess > messing with yet another VCS wouldn't be that good an idea (consider > integration & stuff). OTOH: A bunch of people aren't happy with SVN at all and use git-svn anyways. Just to point it out: while github is hosted only, gitorious[1] is free software and just as amazing. [1] http://gitorious.org -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: discomfitor IN trunk/evas: . src/modules/engines/gl_x11
On Mon, 7 Mar 2011 09:37:37 +0100 (CET) Vincent Torri wrote: > > > On Mon, 7 Mar 2011, Cedric BAIL wrote: > > > On Mon, Mar 7, 2011 at 6:41 AM, Enlightenment SVN > > wrote: > >> Log: > >> fix weird segv I found when trying opengl mode in comp module on my > >> desktop, waiting for someone to give me the "good job you did it > >> correctly" before I backport since I probably didn't > > > > Just reading the patch, seems like you added GLU as a dependency > > without checking for it before ? Does evas already rely on GLU ? > > glu is not checked. But first, why is glu needed (that is, which functions > are part of its API) ? > > Vincent Added it to do some error checking. Someone fix this however it needs to be done, my basement is completely flooded and I will be busy bailing it out for the next several days. -- Mike Blumenkrantz Zentific: NULL pointer dereferences now 50% off! -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Need suggestion to support multiple text parts in elm_progressbar
Hi, I need additional Texts display ( marked as text1, text2, text3 ..). Current progressbar supports only one label, but i need more than one label (ref below fig.). [cid:BSL8PYMC4CBB@namo.co.kr] Currently, we have an API elm_progressbar_label_set() which allows us to set/get one text along with unit. I have a suggestion, to introduce new api to set label for sytle specific part, ex> elm_progressbar_sub_label_set( Evas_Object obj, const char* part_name, const char* label ) Parameter part name can be named in std. way e.g. elm.text, elm.text.sub1, elm.text.sub2. Your input is highly appreciated. Regards, Prince Kr Dubey [SeenTimeChecker?do=efb2749dba5ad35f554175b1dd6ae4c18808ce7c2c034ea52f03c9b1 9f0b6f57ba777c355c197185c465c2cf80a2b7ef9aba4bb3b2b5ca43ddd7e184e0604d958075 b6b33f32d245b7f8aafe245478a5f1d21d5ebee74427cf878f9a26ce15a0] <<201103072155886_EM6S04A2.gif>>-- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] CeBIT 2011 reports
Yeah, I know, pictures don't do me well and I didn't bring my razor so I have a think beard (which I don't usually have). Thanks for the pics Daniel :) On Fri, Mar 4, 2011 at 6:21 PM, Daniel Juyung Seo wrote: > Hello all, > I just updated a group photo with 8 e-developers in one picture :) > > https://picasaweb.google.com/seojuyung/CeBIT2011Enlightenment# > > >From Left : > Hannes Janetzek (jeffdameth - Germany), Leif Middelschulte (T_UNIX - > Germany), Mike Blumenkrantz (discomfitor, zmike - USA), Chuneon Park > (Hermet - Korea), Tom Hacohen (TAsn - Israel), Carsten Haitzler > (Raster - Australia), Brian Miculcy(morlenxus - Germany), Daniel > Juyung Seo (SeoZ - Korea) > > Check out the website! > Thanks. > > Daniel Juyung Seo (SeoZ) > > On Wed, Mar 2, 2011 at 10:50 PM, Daniel Juyung Seo > wrote: > > Hello, > > I uploaded a few more pictures. > > https://picasaweb.google.com/seojuyung/CeBIT2011Enlightenment# > > I would upload more when I have time. > > I can't believe how much I am tired at the moment. > > > > Good night! > > Daniel Juyung Seo (SeoZ) > > > > On Wed, Mar 2, 2011 at 8:56 PM, Alex-P. Natsios > wrote: > >> nice one! any more ? :p would be nice to have a couple of photos for > >> us to see since we couldn't come. > >> > >> we will also have some workshops and talks in the city's university so > >> if more photos are available it would be awesome to showcase even > >> include others from past events if available so that we may get the > >> students there motivated on EFL/E17. > >> > >> -- > >> Regards, > >> > >> Alex-P. Natsios > >> (a.k.a Drakevr) > >> > > > > > -- > What You Don't Know About Data Connectivity CAN Hurt You > This paper provides an overview of data connectivity, details > its effect on application quality, and explores various alternative > solutions. http://p.sf.net/sfu/progress-d2d > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Tom. -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/PROTO/eyelight
On Mon, 7 Mar 2011, Enlightenment SVN wrote: > Log: > eyelight: still fixing DSO. > > > Author: cedric > Date: 2011-03-07 02:55:10 -0800 (Mon, 07 Mar 2011) > New Revision: 57551 > Trac: http://trac.enlightenment.org/e/changeset/57551 > > Modified: > trunk/PROTO/eyelight/configure.ac > > Modified: trunk/PROTO/eyelight/configure.ac > === > --- trunk/PROTO/eyelight/configure.ac 2011-03-07 10:53:31 UTC (rev 57550) > +++ trunk/PROTO/eyelight/configure.ac 2011-03-07 10:55:10 UTC (rev 57551) > @@ -52,6 +52,7 @@ > ecore >= 0.9.9 > ecore-evas >= 0.9.9 > ecore-file >= 0.9.9 > + ecore-x >= 1.0.0 and Windows ? :) Vincent > evas >= 0.9.9 > edje >= 0.5 > emotion >= 0.1 > > > -- > What You Don't Know About Data Connectivity CAN Hurt You > This paper provides an overview of data connectivity, details > its effect on application quality, and explores various alternative > solutions. http://p.sf.net/sfu/progress-d2d > ___ > enlightenment-svn mailing list > enlightenment-...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn > > -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/PROTO/eyelight
On Mon, Mar 7, 2011 at 6:38 PM, Vincent Torri wrote: > On Mon, 7 Mar 2011, Enlightenment SVN wrote: >> Log: >> eyelight: still fixing DSO. >> >> >> Author: cedric >> Date: 2011-03-07 02:55:10 -0800 (Mon, 07 Mar 2011) >> New Revision: 57551 >> Trac: http://trac.enlightenment.org/e/changeset/57551 >> >> Modified: >> trunk/PROTO/eyelight/configure.ac >> >> Modified: trunk/PROTO/eyelight/configure.ac >> === >> --- trunk/PROTO/eyelight/configure.ac 2011-03-07 10:53:31 UTC (rev 57550) >> +++ trunk/PROTO/eyelight/configure.ac 2011-03-07 10:55:10 UTC (rev 57551) >> @@ -52,6 +52,7 @@ >> ecore >= 0.9.9 >> ecore-evas >= 0.9.9 >> ecore-file >= 0.9.9 >> + ecore-x >= 1.0.0 > > and Windows ? :) Yep, I saw that. But the only sane way to remove the ecore_x code from eyelight is to add some maximise feature to ecore_evas_new. That would take me longer to code, so it will come but not today, maybe before the end of the week. -- Cedric BAIL -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] CeBIT 2011 reports
On Mon, Mar 7, 2011 at 17:48, Tom Hacohen wrote: > Yeah, I know, pictures don't do me well and I didn't bring my razor so I > have a think beard (which I don't usually have). You might not be familiar with this, but they actually do sell razors in Germany. :P -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster IN trunk/evas: . src/modules/engines/gl_x11
On Mon, 7 Mar 2011 11:11:19 -0800 "Enlightenment SVN" wrote: > Log: > REVERT! hell no. glu is not going to become a dependency. it never > was. you broke gl-es support and didnt link to glu either. it's a > separate lib. no no no no no. > > > > Author: raster > Date: 2011-03-07 11:11:18 -0800 (Mon, 07 Mar 2011) > New Revision: 57558 > Trac: http://trac.enlightenment.org/e/changeset/57558 > Okay, didn't know about the glu thing but how do I fix the segv? Because now it's back. -- Mike Blumenkrantz Zentific: NULL pointer dereferences now 50% off! -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster IN trunk/evas: . src/modules/engines/gl_x11
On Mon, 7 Mar 2011, Mike Blumenkrantz wrote: > On Mon, 7 Mar 2011 11:11:19 -0800 > "Enlightenment SVN" wrote: > >> Log: >> REVERT! hell no. glu is not going to become a dependency. it never >> was. you broke gl-es support and didnt link to glu either. it's a >> separate lib. no no no no no. >> >> >> >> Author: raster >> Date: 2011-03-07 11:11:18 -0800 (Mon, 07 Mar 2011) >> New Revision: 57558 >> Trac: http://trac.enlightenment.org/e/changeset/57558 >> > Okay, didn't know about the glu thing but how do I fix the segv? Because now > it's back. as i said, do the check in the function, not in the test Vincent -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster IN trunk/evas: . src/modules/engines/gl_x11
On Tue, 8 Mar 2011 00:47:31 +0100 (CET) Vincent Torri wrote: > > > On Mon, 7 Mar 2011, Mike Blumenkrantz wrote: > > > On Mon, 7 Mar 2011 11:11:19 -0800 > > "Enlightenment SVN" wrote: > > > >> Log: > >> REVERT! hell no. glu is not going to become a dependency. it never > >> was. you broke gl-es support and didnt link to glu either. it's a > >> separate lib. no no no no no. > >> > >> > >> > >> Author: raster > >> Date: 2011-03-07 11:11:18 -0800 (Mon, 07 Mar 2011) > >> New Revision: 57558 > >> Trac: http://trac.enlightenment.org/e/changeset/57558 > >> > > Okay, didn't know about the glu thing but how do I fix the segv? Because now > > it's back. > > as i said, do the check in the function, not in the test > > Vincent whoops forgot about that mail -- Mike Blumenkrantz Zentific: NULL pointer dereferences now 50% off! -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] libtool issues recently ... libjpeg.la
Greetings. I've been building from svn via the easy_e17.sh script. Recently, evas and others have been failing when looking for libjpeg.la. My system ( Gentoo / Sabayon ) doesn't like .la files ... I think the distro took a decision to remove .la files from most packages a long while back ( like over a year ago ). There is a script floating around ( fixlafiles.sh ) that scans all .la files on your system and removes broken dependancies. I've run that ( sounds dodgy ... I know ... lots of Gentoo users seem to be running it without issue ), and it cleaned some stuff up. But I still can't get evas to build: make[4]: Entering directory `/home/dkasak/e17_src/evas/src/lib' CC main.lo CCLD libevas.la /bin/grep: /usr/lib64/libjpeg.la: No such file or directory /bin/sed: can't read /usr/lib64/libjpeg.la: No such file or directory libtool: link: `/usr/lib64/libjpeg.la' is not a valid libtool archive make[4]: *** [libevas.la] Error 1 make[4]: Leaving directory `/home/dkasak/e17_src/evas/src/lib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/dkasak/e17_src/evas/src/lib' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/dkasak/e17_src/evas/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/dkasak/e17_src/evas' make: *** [all] Error 2 Any hints on how to get this building again? Thanks. Dan -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libtool issues recently ... libjpeg.la
On Tue, 8 Mar 2011 11:31:15 +1100 Daniel Kasak wrote: > Greetings. > > I've been building from svn via the easy_e17.sh script. Recently, evas > and others have been failing when looking for libjpeg.la. My system > ( Gentoo / Sabayon ) doesn't like .la files ... I think the distro took > a decision to remove .la files from most packages a long while back > ( like over a year ago ). There is a script floating around > ( fixlafiles.sh ) that scans all .la files on your system and removes > broken dependancies. I've run that ( sounds dodgy ... I know ... lots of > Gentoo users seem to be running it without issue ), and it cleaned some > stuff up. But I still can't get evas to build: > > make[4]: Entering directory `/home/dkasak/e17_src/evas/src/lib' > CC main.lo > CCLD libevas.la > /bin/grep: /usr/lib64/libjpeg.la: No such file or directory > /bin/sed: can't read /usr/lib64/libjpeg.la: No such file or directory > libtool: link: `/usr/lib64/libjpeg.la' is not a valid libtool archive > make[4]: *** [libevas.la] Error 1 > make[4]: Leaving directory `/home/dkasak/e17_src/evas/src/lib' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/home/dkasak/e17_src/evas/src/lib' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/home/dkasak/e17_src/evas/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/dkasak/e17_src/evas' > make: *** [all] Error 2 > > Any hints on how to get this building again? > > Thanks. > > Dan > > This email should have been sent to enlightenm...@gentoo.org -- Mike Blumenkrantz Zentific: NULL pointer dereferences now 50% off! -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: discomfitor IN trunk/evas: . src/modules/engines/gl_common
Hey Mike, nice you fixed the segv. Maybe you could also set the corresponding part in e's config back to software. It's pointless that the config says it uses openGL while it doesn't cause it fails to get a context. BR, Leif 2011/3/8 Enlightenment SVN : > Log: > _evas_gl_common_viewport_set segv fix: ROUND 2! > > > Author: discomfitor > Date: 2011-03-07 17:00:21 -0800 (Mon, 07 Mar 2011) > New Revision: 57561 > Trac: http://trac.enlightenment.org/e/changeset/57561 > > Modified: > trunk/evas/ChangeLog > trunk/evas/src/modules/engines/gl_common/evas_gl_context.c > > Modified: trunk/evas/ChangeLog > === > --- trunk/evas/ChangeLog 2011-03-07 22:31:11 UTC (rev 57560) > +++ trunk/evas/ChangeLog 2011-03-08 01:00:21 UTC (rev 57561) > @@ -135,3 +135,7 @@ > 2011-02-27 Vincent Torri > > * Fixed static linking of the bmp, wbmp and tga loaders > + > +2011-03-07 Mike Blumenkrantz > + > + * Fix segv when trying to set gl viewpoint with NULL ctx > > Modified: trunk/evas/src/modules/engines/gl_common/evas_gl_context.c > === > --- trunk/evas/src/modules/engines/gl_common/evas_gl_context.c 2011-03-07 > 22:31:11 UTC (rev 57560) > +++ trunk/evas/src/modules/engines/gl_common/evas_gl_context.c 2011-03-08 > 01:00:21 UTC (rev 57561) > @@ -292,6 +292,7 @@ > GLfloat proj[16]; > int w = 1, h = 1, m = 1, rot = 1, foc = 0; > > + EINA_SAFETY_ON_NULL_RETURN(gc); > foc = gc->foc; > // surface in pipe 0 will be the same as all pipes > if ((gc->pipe[0].shader.surface == gc->def_surface) || > > > -- > What You Don't Know About Data Connectivity CAN Hurt You > This paper provides an overview of data connectivity, details > its effect on application quality, and explores various alternative > solutions. http://p.sf.net/sfu/progress-d2d > ___ > enlightenment-svn mailing list > enlightenment-...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn > -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: discomfitor IN trunk/evas: . src/modules/engines/gl_common
On Tue, 8 Mar 2011 02:11:38 +0100 Leif Middelschulte wrote: > Hey Mike, > > nice you fixed the segv. Maybe you could also set the corresponding > part in e's config back to software. It's pointless that the config > says it uses openGL while it doesn't cause it fails to get a context. > > BR, > > Leif > > 2011/3/8 Enlightenment SVN : > > Log: > > _evas_gl_common_viewport_set segv fix: ROUND 2! > > > > > > Author: discomfitor > > Date: 2011-03-07 17:00:21 -0800 (Mon, 07 Mar 2011) > > New Revision: 57561 > > Trac: http://trac.enlightenment.org/e/changeset/57561 > > No clue how to do that, have to get back to bailing out the basement anyway. -- Mike Blumenkrantz Zentific: NULL pointer dereferences now 50% off! -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: discomfitor IN trunk/evas: . src/modules/engines/gl_common
I'll do it as soon as git.e.fr is in sync with your patch. Hope you're seeing the bottom of your basement soon. BR, Leif 2011/3/8 Mike Blumenkrantz : > On Tue, 8 Mar 2011 02:11:38 +0100 > Leif Middelschulte wrote: > >> Hey Mike, >> >> nice you fixed the segv. Maybe you could also set the corresponding >> part in e's config back to software. It's pointless that the config >> says it uses openGL while it doesn't cause it fails to get a context. >> >> BR, >> >> Leif >> >> 2011/3/8 Enlightenment SVN : >> > Log: >> > _evas_gl_common_viewport_set segv fix: ROUND 2! >> > >> > >> > Author: discomfitor >> > Date: 2011-03-07 17:00:21 -0800 (Mon, 07 Mar 2011) >> > New Revision: 57561 >> > Trac: http://trac.enlightenment.org/e/changeset/57561 >> > > No clue how to do that, have to get back to bailing out the basement anyway. > > -- > Mike Blumenkrantz > Zentific: NULL pointer dereferences now 50% off! > -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libtool issues recently ... libjpeg.la
On Tue, 2011-03-08 at 01:11 +, Mike Blumenkrantz wrote: > On Tue, 8 Mar 2011 11:31:15 +1100 > Daniel Kasak wrote: > > > Greetings. > > > > I've been building from svn via the easy_e17.sh script. Recently, evas > > and others have been failing when looking for libjpeg.la. My system > > ( Gentoo / Sabayon ) doesn't like .la files ... I think the distro took > > a decision to remove .la files from most packages a long while back > > ( like over a year ago ). There is a script floating around > > ( fixlafiles.sh ) that scans all .la files on your system and removes > > broken dependancies. I've run that ( sounds dodgy ... I know ... lots of > > Gentoo users seem to be running it without issue ), and it cleaned some > > stuff up. But I still can't get evas to build: > > > > make[4]: Entering directory `/home/dkasak/e17_src/evas/src/lib' > > CC main.lo > > CCLD libevas.la > > /bin/grep: /usr/lib64/libjpeg.la: No such file or directory > > /bin/sed: can't read /usr/lib64/libjpeg.la: No such file or directory > > libtool: link: `/usr/lib64/libjpeg.la' is not a valid libtool archive > > make[4]: *** [libevas.la] Error 1 > > make[4]: Leaving directory `/home/dkasak/e17_src/evas/src/lib' > > make[3]: *** [all-recursive] Error 1 > > make[3]: Leaving directory `/home/dkasak/e17_src/evas/src/lib' > > make[2]: *** [all-recursive] Error 1 > > make[2]: Leaving directory `/home/dkasak/e17_src/evas/src' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/home/dkasak/e17_src/evas' > > make: *** [all] Error 2 > > > > Any hints on how to get this building again? > > > > Thanks. > > > > Dan > > > > > This email should have been sent to enlightenm...@gentoo.org > Are you sure? I'm not building via portage. I'm building from subversion source, with the easy_e17.sh script. Are you saying that just since I'm using Gentoo that I should direct all build questions to this address? Seems a bit of a cop-out. Dan -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: discomfitor IN trunk/evas: . src/modules/engines/gl_common
So, I had a closer look and... It's weird. e checks the engine support availability based on 'available during compilation of evas'. That doesn't make much sense to me unless autotools are also used to lookup gl symbols within installed drivers. But even then it seems weird as one might distribute e(vas) as packages or install gl supporting drivers later. So proper runtime checking like 'does gl actually work? (context can be created)' instead of 'was evas configured with opengl engine?' is necessary. Sadly I'm not very familiar to tell where in evas this check should be done so that e can rely on that information. BR, Leif 2011/3/8 Leif Middelschulte : > I'll do it as soon as git.e.fr is in sync with your patch. Hope you're > seeing the bottom of your basement soon. > > BR, > > Leif > > 2011/3/8 Mike Blumenkrantz : >> On Tue, 8 Mar 2011 02:11:38 +0100 >> Leif Middelschulte wrote: >> >>> Hey Mike, >>> >>> nice you fixed the segv. Maybe you could also set the corresponding >>> part in e's config back to software. It's pointless that the config >>> says it uses openGL while it doesn't cause it fails to get a context. >>> >>> BR, >>> >>> Leif >>> >>> 2011/3/8 Enlightenment SVN : >>> > Log: >>> > _evas_gl_common_viewport_set segv fix: ROUND 2! >>> > >>> > >>> > Author: discomfitor >>> > Date: 2011-03-07 17:00:21 -0800 (Mon, 07 Mar 2011) >>> > New Revision: 57561 >>> > Trac: http://trac.enlightenment.org/e/changeset/57561 >>> > >> No clue how to do that, have to get back to bailing out the basement anyway. >> >> -- >> Mike Blumenkrantz >> Zentific: NULL pointer dereferences now 50% off! >> > -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libtool issues recently ... libjpeg.la
On Tue, 8 Mar 2011, Daniel Kasak wrote: > Greetings. > > I've been building from svn via the easy_e17.sh script. Recently, evas > and others have been failing when looking for libjpeg.la. My system > ( Gentoo / Sabayon ) doesn't like .la files ... I think the distro took > a decision to remove .la files from most packages a long while back > ( like over a year ago ). There is a script floating around > ( fixlafiles.sh ) that scans all .la files on your system and removes > broken dependancies. I've run that ( sounds dodgy ... I know ... lots of > Gentoo users seem to be running it without issue ), and it cleaned some > stuff up. But I still can't get evas to build: > > make[4]: Entering directory `/home/dkasak/e17_src/evas/src/lib' > CC main.lo > CCLD libevas.la > /bin/grep: /usr/lib64/libjpeg.la: No such file or directory > /bin/sed: can't read /usr/lib64/libjpeg.la: No such file or directory > libtool: link: `/usr/lib64/libjpeg.la' is not a valid libtool archive > make[4]: *** [libevas.la] Error 1 > make[4]: Leaving directory `/home/dkasak/e17_src/evas/src/lib' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/home/dkasak/e17_src/evas/src/lib' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/home/dkasak/e17_src/evas/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/dkasak/e17_src/evas' > make: *** [all] Error 2 > > Any hints on how to get this building again? .la files are not necessary. libtool first look if they exist. If yes, it uses them, otherwise it will search .a files. So, you first built evas while having libjpeg.la files. So libtool creates libevas.la and add in it the dependency of libjpeg as being libjpeg.la and not libjpeg.a (just open libevas.la, it's a text file). You removed libjpeg.la and build again evas. So libtool complains as libjpeg.la is requested in libevas.la but does not exist anymore. Cleaning evas directory (that is : make maintainer-clean, then autogen.sh and make) might be not sufficient because of evas dependencies: evas depends on eet (optionally but i think that you didn't disable the use of eet file or font loaders in evas). Indeed eet also depends on libjpeg. So, in libeet.la, there is also libjpeg.la. Try to rebuild eina. Maybe there will also be the same problem with iconv So, for all the EFL (eina, eet, etc..), do make maintainer-clean ./autogen.sh make install Vincent -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
