headers
Gustavo Sverzut Barbieri | 1 Nov 2008 01:13

Re: [E-devel] E SVN: barbieri IN trunk/evas/src/lib: . canvas

On Fri, Oct 31, 2008 at 4:10 PM, Gustavo Sverzut Barbieri
<barbieri <at> profusion.mobi> wrote:
> On Fri, Oct 31, 2008 at 3:42 PM, Enlightenment SVN
> <no-reply <at> enlightenment.org> wrote:
>> Log:
>>  Add evas_object_table, make evas_object_box more consistent.
>>
>>  Table code is still *incomplete*, it just do homogeneous layouts as
>>  I'm still trying to figure out how to make it great.
>>
>>  I'm not expecting to make layout configurable, as we did for box, but
>>  if you think it's required we can do that later.
>>
>>  Now that the public API of both BOX and TABLE are in, we can add these
>>  as parts of Edje.
>
> Guys,
>
> API is in, code needs to be completed, but as I'll travel to
> Netherlands to participate in ELC-E next week I'll be out of time
> until 13th, I'll need some help.

[...]

I just finished the non-homogeneous layout for tables, now it's
feature complete (possible with bugs, help test!).

Together with Edje, one could help to replace e_table.c and e_box.c,
it's not a drop-in replacement since elm and now evas uses size hints
to provide packing options, but should be easy.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jose Gonzalez | 1 Nov 2008 02:27
Picon
Favicon

Re: [E-devel] Implementing a polygon / image map in edje

Carsten wrote:

> On Thu, 30 Oct 2008 14:46:12 -0700 "Matt Barclay" <mbarclay <at> gmail.com> babbled:
>
>   
>> On Thu, Oct 30, 2008 at 2:14 PM, Jose Gonzalez <jose_ogp <at> juno.com> wrote:
>>     
>>> Matt Barclay wrote:
>>>       
>>>> Hello,
>>>>
>>>> I'm working on an app that let's the user control a chair.  In the
>>>> app, the user will click on the headrest, armrest, seatback, or
>>>> footrest to control its position.  Since these pieces of the chair are
>>>> not rectangles, I'm planning on using some Embryo scripting to get the
>>>> mouse coordinates on the chair, then figure out if the click is inside
>>>> of the controllable areas and emit a signal.  A much cleaner approach,
>>>> I think, would be a part type POLY that would let edje do the heavy
>>>> lifting and behave just like RECT.  I can't be the first person to run
>>>> into this challenge.  How have you solved it in the past?  How hard
>>>> would it be to add POLY to edje?  I see evas already has support for
>>>> polygons.
>>>>
>>>>         
>>>  That sounds like a fun and interesting project. :)
>>>       
>> Yeah, mostly because this is our pilot EFL project!  It's really
>> incredible what these libraries can do and how easy it is to build a
>> development process around graphic design, UI scripting, and
>> application programming.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Carsten Haitzler | 1 Nov 2008 04:15
Favicon
Gravatar

Re: [E-devel] Implementing a polygon / image map in edje

On Fri, 31 Oct 2008 21:27:48 -0400 Jose Gonzalez <jose_ogp <at> juno.com> babbled:

>    And unfortunately you have another set of tough decisions to make for
> both evas and edje.
> 
>    The 'good' news is that, if desired, we can make evas and edje incorporate
> most all vgfx stuff that others have, and some further stuff they don't as
> well, and do so within 3 or 4 months (a bit longer for some extensible
> aspects). The 'bad' news is that in order to 'revamp' not only the vgfx
> capabilities, but also add further gfx abilities, each and every set of such
> revamps will likely mean breaking most of the current engines, and getting
> much of this into edje will likely mean breakage there too.
> 
>    I'd suggest you consider too ways: Either release evas and edje now, and
> start a branch for the 'next' breaking versions and concentrate on those..
> or start breaking evas and edje now. Because the longer you wait on this,
> the more difficult and less likely it will actually get done.

right now e17 is what needs to be done. efl's existance if FOR e17. i dont want
or plan to break anything for it nor do i want to split development effort into
2 branches. i just want to keep vector stuff out UNTIL e17 is out (this means
evas/edje 1.0 will come out etc.). so it'd be the "release then do it after"
option - but the release is going to wait until e17. you may have noticed i
have been knocking off some stuff there of late...

--

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster <at> rasterman.com

-------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jose Gonzalez | 1 Nov 2008 04:38
Picon
Favicon

Re: [E-devel] Implementing a polygon / image map in edje

   Carsten wrote:

> On Fri, 31 Oct 2008 21:27:48 -0400 Jose Gonzalez <jose_ogp <at> juno.com> babbled:
>
>
>   
>>    And unfortunately you have another set of tough decisions to make for
>> both evas and edje.
>>
>>    The 'good' news is that, if desired, we can make evas and edje incorporate
>> most all vgfx stuff that others have, and some further stuff they don't as
>> well, and do so within 3 or 4 months (a bit longer for some extensible
>> aspects). The 'bad' news is that in order to 'revamp' not only the vgfx
>> capabilities, but also add further gfx abilities, each and every set of such
>> revamps will likely mean breaking most of the current engines, and getting
>> much of this into edje will likely mean breakage there too.
>>
>>    I'd suggest you consider too ways: Either release evas and edje now, and
>> start a branch for the 'next' breaking versions and concentrate on those..
>> or start breaking evas and edje now. Because the longer you wait on this,
>> the more difficult and less likely it will actually get done.
>>     
>
> right now e17 is what needs to be done. efl's existance if FOR e17. i dont want
> or plan to break anything for it nor do i want to split development effort into
> 2 branches. i just want to keep vector stuff out UNTIL e17 is out (this means
> evas/edje 1.0 will come out etc.). so it'd be the "release then do it after"
> option - but the release is going to wait until e17. you may have noticed i
> have been knocking off some stuff there of late...
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vincent Torri | 1 Nov 2008 08:23
Picon

Re: [E-devel] IMLIB2 ported to mingw+msys


On Thu, 30 Oct 2008, Kim Woelders wrote:

> On Tue, 28 Oct 2008 17:45:10 +0100, carlo.bramix <carlo.bramix <at> libero.it> 
> wrote:
>
>> Hello,
>> I got the sources of your newly released Imlib2 1.4.2 and I did again the 
>> fixes for Mingw+Msys.
>> I think I also fixed my bugs with:
>> 1) bad mmap() detection
>> 2) wrong use of HAVE_SIGJMP_BUF instead of HAVE_SIGSETJMP.
>> 3) all my files are in unix format.
>> I tested Imlib2 with:
>> - Mingw+Msys
>> - Cygwin
>> - Linux Debian 4.0r3
>> and everything seems to be working.
>> Attached patch includes all those fixes.
>> 
>
> dlfcn-win32.c/h are missing from this patch. I assume they were meant to the 
> same as in the original patch.
>
> Vincent - Do you still want to evilify imlib2? Otherwise I'm fine with this 
> patch (except a few nitpicks I'll fix if/when committed).

I can try to integrate Evil. Right now, i'm trying to make the efl working 
natively on Windows CE. If you can wait a bit (around 1 week), I'll try to 
do it next week end
(Continue reading)

Permalink | Reply | 0 comments |
headers
Viktor Kojouharov | 1 Nov 2008 11:06
Picon

Re: [E-devel] Implementing a polygon / image map in edje

On Fri, 2008-10-31 at 23:38 -0400, Jose Gonzalez wrote:
> Carsten wrote:
> 
> > On Fri, 31 Oct 2008 21:27:48 -0400 Jose Gonzalez <jose_ogp <at> juno.com> babbled:
> >
> >
> >   
> >>    And unfortunately you have another set of tough decisions to make for
> >> both evas and edje.
> >>
> >>    The 'good' news is that, if desired, we can make evas and edje incorporate
> >> most all vgfx stuff that others have, and some further stuff they don't as
> >> well, and do so within 3 or 4 months (a bit longer for some extensible
> >> aspects). The 'bad' news is that in order to 'revamp' not only the vgfx
> >> capabilities, but also add further gfx abilities, each and every set of such
> >> revamps will likely mean breaking most of the current engines, and getting
> >> much of this into edje will likely mean breakage there too.
> >>
> >>    I'd suggest you consider too ways: Either release evas and edje now, and
> >> start a branch for the 'next' breaking versions and concentrate on those..
> >> or start breaking evas and edje now. Because the longer you wait on this,
> >> the more difficult and less likely it will actually get done.
> >>     
> >
> > right now e17 is what needs to be done. efl's existance if FOR e17. i dont want
> > or plan to break anything for it nor do i want to split development effort into
> > 2 branches. i just want to keep vector stuff out UNTIL e17 is out (this means
> > evas/edje 1.0 will come out etc.). so it'd be the "release then do it after"
> > option - but the release is going to wait until e17. you may have noticed i
> > have been knocking off some stuff there of late...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luca De Marini | 1 Nov 2008 11:54
Picon

Re: [E-devel] E-Module_Extra stringshare patch.

Thank you very much man, Extramenu is an important module in OpenGEU, Dave
lately is not answering so I'm really happy you did this :)
Could you do this to trash too pleaaaaaase? I beg you :)
Greetings,

Luca

2008/10/31 Stephane Bauland <joligardon <at> gmail.com>

> Hi all, i notice that evas_stringshare left on some of the modules. Here is
> attached the patch to replac evas_stringshare by eina ones.
>
> PS: I test them quickly, they seem to be working.
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
-------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 2 comments |
headers
Luca De Marini | 1 Nov 2008 12:00
Picon

Re: [E-devel] E-Module_Extra stringshare patch.

Ehm... sorry people, I read a bad topic, I thought it was about emodule
extramenu.... just woke up. I'll try to turn on the brain next time... sorry
again, don't you mind please :(

Lua

2008/11/1 Luca De Marini <luca.darkmaster <at> gmail.com>

> Thank you very much man, Extramenu is an important module in OpenGEU, Dave
> lately is not answering so I'm really happy you did this :)
> Could you do this to trash too pleaaaaaase? I beg you :)
> Greetings,
>
> Luca
>
> 2008/10/31 Stephane Bauland <joligardon <at> gmail.com>
>
>> Hi all, i notice that evas_stringshare left on some of the modules. Here
>> is attached the patch to replac evas_stringshare by eina ones.
>>
>> PS: I test them quickly, they seem to be working.
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephane Bauland | 1 Nov 2008 12:10
Picon
Gravatar

Re: [E-devel] E-Module_Extra stringshare patch.

Luca De Marini wrote:
> Thank you very much man, Extramenu is an important module in OpenGEU, 
> Dave lately is not answering so I'm really happy you did this :)
> Could you do this to trash too pleaaaaaase? I beg you :)
> Greetings,
>
> Luca
I just patch svn modules, but if you want to do it. Then eina keep the 
same API for stringshare than the evas one.

So you can do this : find module/dir -name '*.c' -exec sed -i 
's/evas_stringshare/eina_stringshare/g' {} \;

That will automaticaly replace evas by eina. You just have to test if 
they correctly work after, but their's no prob :)
>
> 2008/10/31 Stephane Bauland <joligardon <at> gmail.com 
> <mailto:joligardon <at> gmail.com>>
>
>     Hi all, i notice that evas_stringshare left on some of the
>     modules. Here is attached the patch to replac evas_stringshare by
>     eina ones.
>
>     PS: I test them quickly, they seem to be working.
>
>
>
>     -------------------------------------------------------------------------
>     This SF.Net email is sponsored by the Moblin Your Move Developer's
>     challenge
(Continue reading)

Permalink | Reply | 0 comments |
headers
carlo.bramix | 1 Nov 2008 12:47
Picon
Favicon

Re: [E-devel] IMLIB2 ported to mingw+msys

Hello,

I tried to analize my changes more in detail.

The mmap() problem with TGA file loader: I could do it natively on Windows too (with CreateFileMapping(),
MapViewOfFile(), etc) but I do not think this is what you really want...
So, this is a good reason for adding the dependency with Evil if mmap() is supported.
As alternative, we can do a simple wrapper to another specific library like LibTGA, which just handle TGA
images as you can probably imagine by its name.
BTW, I improved libTGA a lot because I wanted to use it in my Windows image viewer clone, but it seems I
received no replies from the author... (sigh!).

LibJPEG is normally used with setjmp/longjmp under Windows.
I admit that I do not know if this will corrupt something with IMLIB2.

Into IMLIB2 there are already some #ifdef on EMX.
The coding solution for EMX is good for Windows too.
There is only one wrong thing here and it is the inclusion of pwd.h which do not exists under Windows.
So I simply added the check on pwd.h into configure script.

The "-no-undefined" flag is required for mingw and cygwin, otherwise libtool will never create a shared library.
There are no much work-arounds here.

I added macro IMLIB2_IS_COMPILING to distinguish the compilation of IMLIB2 from the applications. There
was already BUILDING_DLL with a similar purpose, but if a library depends from IMLIB2 and it uses
BUILDING_DLL too, it will happen an error because an import/export confict (I already encountered such
problems in the past).
If I can give a suggestion, I would use a different name here.

Some functions are missing, (mkstemp, dlopen, etc) but doing a replacement is very easy even for me ;)
(Continue reading)

Permalink | Reply | 501 comments |

Gmane