Re: [E-devel] [win32] some evilness
On Fri, 15 Feb 2008, Mike Frysinger wrote:
Another thing I've discovered is how libtool manages the export of the
functions on Windows. Everything is done with EAPI with a small
modification. But, contrary to gcc on linux, which does not complain when
EAPI is used on declaration and definition of the functions, on Windows
there is an error. So I have to define to nothing EAPI on Windows. I added
that in eet_lib.c, eet_data.c and eet_image.c.
can you elaborate ? you're saying that this fails on windows:
EAPI void foo(void);
EAPI void foo(void) {}
and so you need to undefine EAPI before the function definition ?
I was indeed not clear. Yes, using __declspec(dll[ex/im]port) in both
declaration and definition fails during the compilation. So i have to not
only undef EAPI, but I also have to define it to nothing.
Another solution would be to remove EAPI on definitions of the exported
functions (it's sufficient to have it on declarations). But raster prefers
to keep them as it shows which functions are really exported in the .c
files. I think that it can be replaced by organising the files like that:
as long as gcc sees the function prototype first with all attributes declared
there, all attributes can be removed from the function definition. perhaps a
middle ground would be to use EAPI in the headers and then use a slightly
different define in the source "EAPI_DEF" ...
that could be a solution.
-libeet_la_LIBADD = -lz -ljpeg @fnmatch_libs@ @winsock_libs@ -lm
+libeet_la_LIBADD = @EVIL_LIBS@ -lz -ljpeg @fnmatch_libs@
@win32_libs@ -lm
i think EVIL_LIBS will have to come last rather than first
Actually, as it's only Windows flags, EVIL_LIBS is independent of the
other flags, so it should not matter. On linux, it will not be used as
EVIL_LIBS will be empty. On Windows, i didn't see any problem.
Vincent-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl and Edje
> Another wrinkle is that we'd like to create a core library that is > only loosely tied to any specific underlying display system. We're > still in the process of abstracting the evas and edje specifics into > engines, and I don't want to add too many more direct dependencies. > This could be done as a library add-on to provide an ewl_evas widget > without breaking that abstraction. I That seems like a good way to do it. Note for example that Hisham did a similar thing in etk with an etk_cairo widget, something which you might also want to indulge in as well. :) I think Hisham's work on evolve is also very promising, and he's told me that he'd like to have it 'engine-based' so that it could be used for etk, ewl, raster-widgetry(?). BTW, as a distantly related aside here: The topic has often come up of buffered rendering in evas and of transforms for evas objs, it's something many people want.. and can be adadpted to includes gui- toolkit widgets and such. So, let me bring it up here a bit. In general, there are many 'kinds' of canvases - html ones, svg ones, mixed such ones, canvases of vgfx objects (like some cairo or qt based ones around), evas, edje (yes that can be considered one, just add a few move,resize,... api funcs to edje and you can forget that it comes from evas), and of course even ewl and etk and the like. Now, the thing about evas and edje is that they tend to want to restrict themselves to pixel-aligned objects (much like an html canvas). This makes it easy to deal with layout, alignement, and event handling. But people would like transformed objects, and fractionally positioned objects.. I spent some time looking into this, and discussed it somewhat with Carsten, and we both agree that it would be a 'bad' thing to add transforms to evas objects, per-se. It would create all sorts of issues and problems with semantics and layout/alignment and event handling and ghosts and monsters start to appear and whatnot. The best way (at least we feel so) to introduce such notions to evas objects (not only primitives like images, rects,... but also compound objs like edjes or just any smart-object) is indirectly via something much like a canvas-widget as we've been talking about here, though better to call it something like an "evas_drawing" object. Basically, one'd just add evas objects to this type of object, and set transforms on the so bound child obj of the drawing obj. This is actually fairly easy to do - for the primitive evas objects of rect, image, polys,.. all the needed gfx code is already there for it (see eg. some of Jorge's work in enesim for software versions). But for things like edje objects, or general smart-objects, or other drawing objects.. well, that requires being able to render to buffers in evas.. which itself is not that difficult to do (need code for the gl engine, but all the others are fairly straightforward). However, when you put all this together.. it becomes a massive re-write of much of evas' internals -- and that's what's blocking any work on evas to get these kinds of capabilities.. It's all there, but no one is sufficiently motivated to put that much time and effort to do the necessary re-write. I certainly find myself somewhat short of that at the moment. It may well be the case that it's better to just start from scratch with a new version of evas.. something based on a far more flexible canvas approach that would enable building not only evas, but also the various other kinds of canvases that people find of interest.. and again Jorge has done a large amount of work there, as part of his 'efl-research'. _ Click here to find the right stock, bonds, and mutual funds. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mJ0S2Z6jYgZqkPp5xP2BJX5hiezlA6aZWaMexYCeVky2wwo/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl and Edje
On Feb 15, 2008, at 8:36 PM, Nathan Ingersoll wrote: > > > Yeah, unfortunately my participation at SCALE fell through. I'm not > sure if raster made it, but it would be good to hear a trip report if > he did. :-) http://arstechnica.com/news.ars/post/20080211-the-enlightened-future-of-openmoko-linux-mobile-phones.html -Blake - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl and Edje
On Fri, Feb 15, 2008 at 10:05 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Good questions.. Don't know. A buffer canvas would be nice to > have for several reasons, but as you mention it may not be the best > way to realize a canvas widget for other reasons.. it also depends on > the semantic notions of child widgets vs sub-canvases. I think etk > takes a canvas widget as just a region of the underlying canvas of > the parent widget, and just feeds the events to that evas. Another wrinkle is that we'd like to create a core library that is only loosely tied to any specific underlying display system. We're still in the process of abstracting the evas and edje specifics into engines, and I don't want to add too many more direct dependencies. This could be done as a library add-on to provide an ewl_evas widget without breaking that abstraction. I > My itching has calmed down quite a bit over time since it > often feels like too much of a battle here in E land.. I'd hoped > to see some of the things Carsten mentioned he'd like to engage > edevelopers in - meets, discussions, coordination in plans, maybe > some hackfests, etc.. but it seems that kind of organization itself > takes more time than anyone really has.. :( Yeah, unfortunately my participation at SCALE fell through. I'm not sure if raster made it, but it would be good to hear a trip report if he did. :-) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl and Edje
> > Umm... It still sems to me like you'd want some kind of canvas > > widget to which one could add arbitrary evas objects to, directly > > or indirectly (I believe that etk has something like that), in > > order to have a more flexible "evas objs in a ewl app" system, and > > just feed ewl events on that canvas widget to the underlying evas.. > > The idea of a canvas has been under consideration for a while, but > has been lower priority than other things that still need work. > > Through what mechanism are you proposing we build the canvas widget? > It could be a buffer evas as we already have a pretty good wrapper > around that, but the levels of indirection are additional overhead > (maybe a reasonable amount). That would solve the problem of feeding > events since they could go directly through the global evas event API > I'd prefer to have a sub-canvas abstraction around the windows > existing evas, which we can clip to the region of the canvas widget. Good questions.. Don't know. A buffer canvas would be nice to have for several reasons, but as you mention it may not be the best way to realize a canvas widget for other reasons.. it also depends on the semantic notions of child widgets vs sub-canvases. I think etk takes a canvas widget as just a region of the underlying canvas of the parent widget, and just feeds the events to that evas. > > > But as far as the particular events issue you bring up, > > maybe you could write up a preliminary evas patch with the changes/ > > additions you feel are needed.. and battle it out with raster if > > need be. :) > > I'm not sure if you've noticed my commit level lately, but it hasn't > been what I would call "active". I'll look at this if have a chunk It's been better than mine.. > of time to commit to it, but I'm hoping someone with an itch to > scratch will beat me to it. My itching has calmed down quite a bit over time since it often feels like too much of a battle here in E land.. I'd hoped to see some of the things Carsten mentioned he'd like to engage edevelopers in - meets, discussions, coordination in plans, maybe some hackfests, etc.. but it seems that kind of organization itself takes more time than anyone really has.. :( _ Music to your ears. Click now for great mp3 accessories! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oh9kw8rO5cy05pZf7Z6vqaNFwfzyTG45gGYhqutlSXvsQ44/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl and Edje
On Fri, Feb 15, 2008 at 3:50 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Umm... It still sems to me like you'd want some kind of canvas > widget to which one could add arbitrary evas objects to, directly or > indirectly (I believe that etk has something like that), in order to > have a more flexible "evas objs in a ewl app" system, and just feed ewl > events on that canvas widget to the underlying evas..? The idea of a canvas has been under consideration for a while, but has been lower priority than other things that still need work. Through what mechanism are you proposing we build the canvas widget? It could be a buffer evas as we already have a pretty good wrapper around that, but the levels of indirection are additional overhead (maybe a reasonable amount). That would solve the problem of feeding events since they could go directly through the global evas event API. I'd prefer to have a sub-canvas abstraction around the windows existing evas, which we can clip to the region of the canvas widget. > But as far as the particular events issue you bring up, maybe > you could write up a preliminary evas patch with the changes/additions > you feel are needed.. and battle it out with raster if need be. :) I'm not sure if you've noticed my commit level lately, but it hasn't been what I would call "active". I'll look at this if have a chunk of time to commit to it, but I'm hoping someone with an itch to scratch will beat me to it. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [win32] some evilness
On Friday 15 February 2008, Vincent Torri wrote:
> as the Windows Mobile platform is trying to be supported, a lot of #ifdef
> might appear. So I began to move the win32 code from the efl to a single
> lib (named 'evil'). The source code for that lib is attached, for those
> who are interested. Currently, the main functions that are ported are dl*
> functions, mmap and munmap, and fcntl.
thanks for doing this ... i know it probably wasnt fun
> Another thing I've discovered is how libtool manages the export of the
> functions on Windows. Everything is done with EAPI with a small
> modification. But, contrary to gcc on linux, which does not complain when
> EAPI is used on declaration and definition of the functions, on Windows
> there is an error. So I have to define to nothing EAPI on Windows. I added
> that in eet_lib.c, eet_data.c and eet_image.c.
can you elaborate ? you're saying that this fails on windows:
EAPI void foo(void);
EAPI void foo(void) {}
and so you need to undefine EAPI before the function definition ?
> Another solution would be to remove EAPI on definitions of the exported
> functions (it's sufficient to have it on declarations). But raster prefers
> to keep them as it shows which functions are really exported in the .c
> files. I think that it can be replaced by organising the files like that:
as long as gcc sees the function prototype first with all attributes declared
there, all attributes can be removed from the function definition. perhaps a
middle ground would be to use EAPI in the headers and then use a slightly
different define in the source "EAPI_DEF" ...
> RCS file: /cvs/e/e17/libs/eet/src/lib/Makefile.am,v
> --- src/lib/Makefile.am 4 Nov 2007 09:10:50 - 1.17
> +++ src/lib/Makefile.am 10 Feb 2008 23:20:38 -
> @@ -18,6 +19,6 @@
> eet_utils.c \
> Eet_private.h
>
> -libeet_la_LIBADD = -lz -ljpeg @fnmatch_libs@ @winsock_libs@ -lm
> +libeet_la_LIBADD = @EVIL_LIBS@ -lz -ljpeg @fnmatch_libs@
> @win32_libs@ -lm
i think EVIL_LIBS will have to come last rather than first
-mike
signature.asc
Description: This is a digitally signed message part.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [win32] some evilness
Hey,
as the Windows Mobile platform is trying to be supported, a lot of #ifdef
might appear. So I began to move the win32 code from the efl to a single
lib (named 'evil'). The source code for that lib is attached, for those
who are interested. Currently, the main functions that are ported are dl*
functions, mmap and munmap, and fcntl.
There is also a patch for eet that is attached. It shows the modifications
in eet when 'evil' is used. It's not so evil, finally :)
Another thing I've discovered is how libtool manages the export of the
functions on Windows. Everything is done with EAPI with a small
modification. But, contrary to gcc on linux, which does not complain when
EAPI is used on declaration and definition of the functions, on Windows
there is an error. So I have to define to nothing EAPI on Windows. I added
that in eet_lib.c, eet_data.c and eet_image.c.
I can also add it in Eet_private.h, but I have to include Eet_private.h
after Eet.h.
Another solution would be to remove EAPI on definitions of the exported
functions (it's sufficient to have it on declarations). But raster prefers
to keep them as it shows which functions are really exported in the .c
files. I think that it can be replaced by organising the files like that:
static declarations and non exported functions
definitions of exported functions
definitions of non exported functions
definitions of static functions
and by adding good comments.
It's easy to manage EAPI with eet. I let you imagine with a beast like
evas (I have the diff somewhere. It's quite ugly)
comments, ideas are welcome.
Vincent? eet_win32.diff
Index: configure.in
===
RCS file: /cvs/e/e17/libs/eet/configure.in,v
retrieving revision 1.84
diff -u -r1.84 configure.in
--- configure.in26 Jan 2008 05:52:47 - 1.84
+++ configure.in10 Feb 2008 23:20:37 -
@@ -30,22 +30,23 @@
AC_FUNC_ALLOCA
-AC_CHECK_HEADER(zlib.h,, AC_MSG_ERROR("Cannot find zlib.h. Make sure your
CFLAGS environment variable contains include lines for the location of this
file"))
-AC_CHECK_HEADER(jpeglib.h,, AC_MSG_ERROR("Cannot find jpeglib.h. Make sure
your CFLAGS environment variable contains include lines for the location of
this file"))
-
-AC_CHECK_HEADERS_ONCE(netinet/in.h sys/mman.h windows.h winsock2.h)
-
-winsock_libs=""
+win32_libs=""
create_shared_lib=""
case "$host_os" in
mingw|mingw32)
- winsock_libs="-lwsock32"
+ PKG_CHECK_MODULES([EVIL], evil)
+ AC_DEFINE(HAVE_EVIL, 1, [Set to 1 if evil package is installed])
+ win32_libs="-lws2_32"
create_shared_lib="-no-undefined "
;;
esac
-
-AC_SUBST(winsock_libs)
+AC_SUBST(win32_libs)
AC_SUBST(create_shared_lib)
+
+AC_CHECK_HEADER(zlib.h,, AC_MSG_ERROR("Cannot find zlib.h. Make sure your
CFLAGS environment variable contains include lines for the location of this
file"))
+AC_CHECK_HEADER(jpeglib.h,, AC_MSG_ERROR("Cannot find jpeglib.h. Make sure
your CFLAGS environment variable contains include lines for the location of
this file"))
+
+AC_CHECK_HEADERS(netinet/in.h)
AC_CHECK_HEADER(fnmatch.h,, AC_MSG_ERROR([Cannot find fnmatch.h. Make sure
your CFLAGS environment variable contains include lines for the location of
this file. MinGW users: see the INSTALL file]))
Index: src/lib/Eet.h
===
RCS file: /cvs/e/e17/libs/eet/src/lib/Eet.h,v
retrieving revision 1.44
diff -u -r1.44 Eet.h
--- src/lib/Eet.h 27 Jan 2008 13:08:30 - 1.44
+++ src/lib/Eet.h 10 Feb 2008 23:20:38 -
@@ -6,8 +6,8 @@
#ifdef EAPI
#undef EAPI
#endif
-#ifdef _MSC_VER
-# ifdef BUILDING_DLL
+#ifdef _WIN32
+# ifdef DLL_EXPORT
# define EAPI __declspec(dllexport)
# else
# define EAPI __declspec(dllimport)
Index: src/lib/Eet_private.h
===
RCS file: /cvs/e/e17/libs/eet/src/lib/Eet_private.h,v
retrieving revision 1.18
diff -u -r1.18 Eet_private.h
--- src/lib/Eet_private.h 26 Jan 2008 05:50:09 - 1.18
+++ src/lib/Eet_private.h 10 Feb 2008 23:20:38 -
@@ -33,8 +33,9 @@
#ifdef HAVE_NETINET_IN_H
# include
#endif
-#ifdef HAVE_WINSOCK2_H
-# include
+
+#ifdef HAVE_EVIL
+# include
#endif
#include
Index: src/lib/Makefile.am
===
RCS file: /cvs/e/e17/libs/eet/src/lib/Makefile.am,v
retrieving revision 1.17
diff -u -r1.17 Makefile.am
--- src/lib/Makefile.am 4 Nov 2007 09:10:50 - 1.17
+++ src/lib/Makefile.am 10 Feb 2008 23:20:38 -
@@ -6,7 +6,8 @@
-I$(top_srcdir)/src/lib \
-DPACKAGE_BIN_DIR=\"$(bindir)\" \
-DPACKAGE_LIB_DIR=\"$(libdir)\" \
--DPACKAGE_DATA_DIR=\"$(datadir)/$(PACKAGE)\"
+-DPACKAGE_DATA_DIR=\"$(datadir)/$(PACKAGE)\" \
[EMAIL PROTECTED]@
lib_LTLIBRARIES = libeet.la
include_HEADERS = Eet.h
@@ -18
Re: [E-devel] Ewl and Edje
> > Until a more generic solution presents itself, why not have > > a separate Ewl_Evas lib, with say a 'ewl_evas' widget, that has > > a function to get an underlying evas..? > > Getting to the evas is not a problem: > > embed = ewl_embed_widget_find(some_widget_on_my_evas); > evas = embed->canvas; /* Should probably write a _get for this as > we have a _set */ > > The problem comes down to the event dispatching, since EWL marshals > it's own events (for a variety of reasons). We would still need a way > to feed event dispatching into Evas for a sub-tree of the objects on > the Evas. Umm... It still sems to me like you'd want some kind of canvas widget to which one could add arbitrary evas objects to, directly or indirectly (I believe that etk has something like that), in order to have a more flexible "evas objs in a ewl app" system, and just feed ewl events on that canvas widget to the underlying evas..? But as far as the particular events issue you bring up, maybe you could write up a preliminary evas patch with the changes/additions you feel are needed.. and battle it out with raster if need be. :) _ Click to get information on how to convert your home equity into cash with a reverse mortgage. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mI5r1fcZsC2CxSOZLFsNLviDuKojDR5z76gSgJXAG11o3gs/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Reduce memory allocation for edje match.
On Fri, Feb 15, 2008 at 3:25 PM, Cedric BAIL <[EMAIL PROTECTED]> wrote:
> This new patch just allocate and build the match automate for
> callbacks and programs only when required. On load for programs and
> when callbacks list has been updated.
Just catched a memory leak thanks to Gustavo. So just attached an
updated patch with some cosmetic change also.
--
Cedric BAIL
diff -Nrua -X exclude.cvs e17-clean/libs/edje/src/lib/edje_load.c e17-dev/libs/edje/src/lib/edje_load.c
--- e17-clean/libs/edje/src/lib/edje_load.c 2008-02-06 17:40:08.0 +0100
+++ e17-dev/libs/edje/src/lib/edje_load.c 2008-02-15 17:24:46.0 +0100
@@ -410,6 +410,15 @@
rp->text.text_source = ed->table_parts[rp->param1.description->text.id_text_source % ed->table_parts_size];
}
}
+
+if (ed->patterns.programs.signals_patterns)
+ {
+ edje_match_patterns_free(ed->patterns.programs.signals_patterns);
+ edje_match_patterns_free(ed->patterns.programs.sources_patterns);
+ }
+ed->patterns.programs.signals_patterns = edje_match_programs_signal_init(ed->collection->programs);
+ed->patterns.programs.sources_patterns = edje_match_programs_source_init(ed->collection->programs);
+
n = evas_list_count(ed->collection->programs);
if (n > 0)
{
diff -Nrua -X exclude.cvs e17-clean/libs/edje/src/lib/edje_match.c e17-dev/libs/edje/src/lib/edje_match.c
--- e17-clean/libs/edje/src/lib/edje_match.c 2008-01-18 07:34:04.0 +0100
+++ e17-dev/libs/edje/src/lib/edje_match.c 2008-02-15 16:37:38.0 +0100
@@ -14,7 +14,6 @@
size_tpos;
};
-typedef struct _Edje_States Edje_States;
struct _Edje_States
{
size_t size;
@@ -37,12 +36,13 @@
Size++;\
};
-static Edje_States*
-_edje_match_states_alloc(size_t n,
- size_t patterns_size,
- size_t patterns_max_length)
+static int
+_edje_match_states_alloc(Edje_Patterns *ppat, int n)
{
- Edje_States *l;
+ Edje_States *l;
+
+ const size_t patterns_size = ppat->patterns_size;
+ const size_t patterns_max_length = ppat->max_length;
const size_t array_len = (patterns_max_length + 1) * patterns_size;
@@ -69,8 +69,9 @@
struct_size += states_has_size;
l = malloc(n * struct_size);
- if (!l) return NULL;
+ if (!l) return 0;
+ ppat->states = l;
states = (unsigned char *) (l + n);
has = states + states_size;
@@ -82,7 +83,7 @@
has += states_has_size;
}
- return l;
+ return 1;
}
static void
@@ -295,6 +296,12 @@
lst = evas_list_next(lst);\
}\
\
+ if (!_edje_match_states_alloc(r, 2)) \
+ {\
+ free(r); \
+ return NULL; \
+ }\
+\
return r; \
}
@@ -451,22 +458,16 @@
edje_match_collection_dir_exec(const Edje_Patterns *ppat,
const char *string)
{
- Edje_States *states = _edje_match_states_alloc(2,
- ppat->patterns_size,
- ppat->max_length);
Edje_States *result;
int r = 0;
- if (!states)
- return 0;
- _edje_match_patterns_exec_init_states(states, ppat->patterns_size, ppat->max_length);
+ _edje_match_patterns_exec_init_states(ppat->states, ppat->patterns_size, ppat->max_length);
- result = _edje_match_fn(ppat, string, states);
+ result = _edje_match_fn(ppat, string, ppat->states);
if (result)
r = _edje_match_collection_dir_exec_finals(ppat->finals, result);
- _edje_match_states_free(states, 2);
return r;
}
@@ -479,28 +480,19 @@
int (*func)(Edje_Program *pr, void *data),
void *data)
{
- Edje_States *signal_states = _edje_match_states_alloc(2,
- ppat_signal->patterns_size,
- ppat_signal->max_length);
- Edje_States *source_states = _edje_match_states_alloc(2,
- ppat_source->patterns_size,
- ppat_source->max_length);
Edje_States *signal_result;
Edje_States *source_result;
int r = 0;
- if (!signal_states || !source_states)
- return 0;
-
- _edje_match_patterns_exec_init_st
Re: [E-devel] Ewl and Edje
On Fri, Feb 15, 2008 at 2:01 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > That seems to me like it might be a BIG problem for any > sufficiently flexible use of ewl and evas. :( > > Until a more generic solution presents itself, why not have > a separate Ewl_Evas lib, with say a 'ewl_evas' widget, that has a > function to get an underlying evas..? Getting to the evas is not a problem: embed = ewl_embed_widget_find(some_widget_on_my_evas); evas = embed->canvas; /* Should probably write a _get for this as we have a _set */ The problem comes down to the event dispatching, since EWL marshals it's own events (for a variety of reasons). We would still need a way to feed event dispatching into Evas for a sub-tree of the objects on the Evas. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] Reduce memory allocation for edje match.
This new patch just allocate and build the match automate for
callbacks and programs only when required. On load for programs and
when callbacks list has been updated.
--
Cedric BAIL
diff -Nrua -X exclude.cvs e17-clean/libs/edje/src/lib/edje_load.c e17-dev/libs/edje/src/lib/edje_load.c
--- e17-clean/libs/edje/src/lib/edje_load.c 2008-02-06 17:40:08.0 +0100
+++ e17-dev/libs/edje/src/lib/edje_load.c 2008-02-14 16:37:17.0 +0100
@@ -411,6 +411,8 @@
}
}
n = evas_list_count(ed->collection->programs);
+ed->patterns.programs.signals_patterns = edje_match_programs_signal_init(ed->collection->programs);
+ed->patterns.programs.sources_patterns = edje_match_programs_source_init(ed->collection->programs);
if (n > 0)
{
/* FIXME: keeping a table AND a list is just bad - nuke list */
diff -Nrua -X exclude.cvs e17-clean/libs/edje/src/lib/edje_match.c e17-dev/libs/edje/src/lib/edje_match.c
--- e17-clean/libs/edje/src/lib/edje_match.c 2008-01-18 07:34:04.0 +0100
+++ e17-dev/libs/edje/src/lib/edje_match.c 2008-02-11 20:00:12.0 +0100
@@ -14,7 +14,6 @@
size_tpos;
};
-typedef struct _Edje_States Edje_States;
struct _Edje_States
{
size_t size;
@@ -37,12 +36,13 @@
Size++;\
};
-static Edje_States*
-_edje_match_states_alloc(size_t n,
- size_t patterns_size,
- size_t patterns_max_length)
+static int
+_edje_match_states_alloc(Edje_Patterns *ppat, int n)
{
- Edje_States *l;
+ Edje_States *l;
+
+ const size_t patterns_size = ppat->patterns_size;
+ const size_t patterns_max_length = ppat->max_length;
const size_t array_len = (patterns_max_length + 1) * patterns_size;
@@ -69,8 +69,9 @@
struct_size += states_has_size;
l = malloc(n * struct_size);
- if (!l) return NULL;
+ if (!l) return -1;
+ ppat->states = l;
states = (unsigned char *) (l + n);
has = states + states_size;
@@ -82,7 +83,7 @@
has += states_has_size;
}
- return l;
+ return 0;
}
static void
@@ -295,6 +296,12 @@
lst = evas_list_next(lst);\
}\
\
+ if (_edje_match_states_alloc(r, 2))\
+ {\
+ free(r); \
+ return NULL; \
+ }\
+\
return r; \
}
@@ -451,22 +458,16 @@
edje_match_collection_dir_exec(const Edje_Patterns *ppat,
const char *string)
{
- Edje_States *states = _edje_match_states_alloc(2,
- ppat->patterns_size,
- ppat->max_length);
Edje_States *result;
int r = 0;
- if (!states)
- return 0;
- _edje_match_patterns_exec_init_states(states, ppat->patterns_size, ppat->max_length);
+ _edje_match_patterns_exec_init_states(ppat->states, ppat->patterns_size, ppat->max_length);
- result = _edje_match_fn(ppat, string, states);
+ result = _edje_match_fn(ppat, string, ppat->states);
if (result)
r = _edje_match_collection_dir_exec_finals(ppat->finals, result);
- _edje_match_states_free(states, 2);
return r;
}
@@ -479,28 +480,19 @@
int (*func)(Edje_Program *pr, void *data),
void *data)
{
- Edje_States *signal_states = _edje_match_states_alloc(2,
- ppat_signal->patterns_size,
- ppat_signal->max_length);
- Edje_States *source_states = _edje_match_states_alloc(2,
- ppat_source->patterns_size,
- ppat_source->max_length);
Edje_States *signal_result;
Edje_States *source_result;
int r = 0;
- if (!signal_states || !source_states)
- return 0;
-
- _edje_match_patterns_exec_init_states(signal_states,
+ _edje_match_patterns_exec_init_states(ppat_signal->states,
ppat_signal->patterns_size,
ppat_signal->max_length);
- _edje_match_patterns_exec_init_states(source_states,
+ _edje_match_patterns_exec_init_states(ppat_source->states,
ppat_source->patterns_size,
ppat_source->max_length);
Re: [E-devel] [PATH] Some little bug
On Fri, Feb 15, 2008 at 11:20 AM, Cedric BAIL <[EMAIL PROTECTED]> wrote: > Just two little bugs i found thanks to valgrind : > > - in evas_object_textblock, the length forgot the '\0', this create a > buffer overrun. > > - in evas_font_main, every thing is not really cleaned on shutdown (It > make it crash, if you shutdown completely the font system and then > restart it again). Both looks fine, applied. -- Gustavo Sverzut Barbieri http://profusion.mobi - Embedded and Mobile Software Development -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATH] Some little bug
Just two little bugs i found thanks to valgrind :
- in evas_object_textblock, the length forgot the '\0', this create a
buffer overrun.
- in evas_font_main, every thing is not really cleaned on shutdown (It
make it crash, if you shutdown completely the font system and then
restart it again).
--
Cedric BAIL
diff -Nrua -X exclude.cvs e17-clean/libs/evas/src/lib/engines/common/evas_font_main.c e17-dev/libs/evas/src/lib/engines/common/evas_font_main.c
--- e17-clean/libs/evas/src/lib/engines/common/evas_font_main.c 2007-09-28 14:34:09.0 +0200
+++ e17-dev/libs/evas/src/lib/engines/common/evas_font_main.c 2007-09-27 17:22:40.0 +0200
@@ -25,7 +25,12 @@
initialised--;
if (initialised != 0) return;
+
+ evas_common_font_cache_set(0);
+ evas_common_font_flush();
+
error = FT_Done_FreeType(evas_ft_lib);
+ evas_ft_lib = 0;
}
EAPI int
diff -Nrua -X exclude.cvs e17-clean/libs/evas/src/lib/canvas/evas_object_textblock.c e17-dev/libs/evas/src/lib/canvas/evas_object_textblock.c
--- e17-clean/libs/evas/src/lib/canvas/evas_object_textblock.c 2008-02-14 14:28:35.0 +0100
+++ e17-dev/libs/evas/src/lib/canvas/evas_object_textblock.c 2008-02-14 14:27:11.0 +0100
@@ -259,7 +259,7 @@
return strdup("");
}
l2 = strlen(s2);
- tlen = *len + l2;
+ tlen = *len + l2 + 1;
if (tlen > *alloc)
{
char *ts;
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl and Edje
> > Does ewl have something like a canvas widget that one can add > > evas objects to? > > Not atm. That seems to me like it might be a BIG problem for any sufficiently flexible use of ewl and evas. :( Until a more generic solution presents itself, why not have a separate Ewl_Evas lib, with say a 'ewl_evas' widget, that has a function to get an underlying evas..? _ Click here for financial aid options. Quick and Easy. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oIGkNxoRjRxe4thXzy5MRk0x8J6Q6n8cIKpq1vVMPQTRjgE/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
