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
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
make it
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
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
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; /*
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
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.
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
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
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
On Feb 15, 2008, at 8:36 PM, Nathan Ingersoll wrote:
snip
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. :-)
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
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
14 matches
Mail list logo
