> > 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_Ev
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).
--
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
> m
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-cl
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
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 j
> > 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-
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
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. Cur
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
>
> > 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
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
>
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-l
> 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 don
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
15 matches
Mail list logo