Re: [E-devel] terminal application based on the efl.

2008-10-20 Thread Jose Gonzalez

 using freetype directly probably.

 Again, this is easier to do IMO. Doing that inside Evas will be bit
 harder I guess, maybe not because engine stuff remains unchanged
 you know better than me, does it worth to have such restricted-use
 object built-in in Evas?
 
 
 much easier to do inside evas. trust me. much easier :) and more efficient.

   
   
Yes, for current evas - without a doubt more efficient. The 'problem' with
 this is that it's really 'covering up' a more general issue that evas needs
 to address - make it easier/possible to do efficient 'custom' rendering or
 define custom 'self-rendered' objs.
Right now there's really only one way, software rendering to an argb 
 image.
 We can extend this to a similar buffered solution which is more engine
 specific via things like native surfaces (which is useful in its own right),
 but still an 'indirect' solution.
 

 well smart object with a grid of NxM text objects... but thats just nasty
 overhead... :)

   

   Yes, a more 'direct' rendering solution is likely preferable here...

We know evas needs to be able to support more direct custom 
 rendering/objs,
 the question is simply how to go about doing that.. because there are several
 ways in which one could realize it (I'll refrain from going into those here).
 

 yeah - absolutely. need to be able to create 1st-class evas objects by
 providing a paint method basically. but as such this is exactly what is done
 inside of evas anyway - just there is no external access to that api, that's
 all. you'll end up implementing the same thing. the only question will be
 where does that implementation live :)

   

   ... And what kind of 'api', if any, should be provided for custom 
rendering - eg. an
 api of some sort for immediate-mode to an 'abstract' update surface? or 
per-engine
update surfaces you draw to as fits that engine? or somehow use the 
canvas objs to
do immediate-mode rendering (change state and set a 'draw')? or others...

But if we're talking about whether evas should extend its current api to
 include something like a 'multi-line text obj' or something of that sort...
 well, that depends.
Does one want to keep adding more and more specialized stuff right now,
 though it would be useful/efficient for this or that thing one wants now.. or
 take the time to fix the 'real' underlying issues the lib must invariably
 face long-term?
 

 of course not - but there is a limit. i think evas has very much not suffered
 from much of this and has remained very clean and simple - a textgrid object
 does make a lot of sense. a buffer u render to and keep is a little silly as u
 keep argb pixels around for stuff u can generate on the fly pretty fast anyway
 from glyphs. :)

   

   Doing it by drawing to an image buffer would be, generally, less 
efficient.. and one
could agree that a 'textgrid' obj is fairly basic. But these kinds of 
things have a way
of snow-balling.. I mean, first text objs, then it was argued textblock 
objs, now it's yet
another text related obj.. and there arguments for all sorts of 'extras' 
one might want along
with that, and ...

   What would be 'nice', and is doable now, would be the basics of 
custom objs.
ie. separately declared objs (ie. their apis) which the lib could load.. 
even if their
implementation would be much like what is done now and would still depend
on knowing evas internals.
   It'd be a step towards a more complete solution and gives the option 
to later
move such objs' implementation (if desired) to a true 'custom rendering' 
one.
   It would allow for such things as a 'cairo' obj (which could draw to 
native update
surfaces in some cases), for your text-grid, for funky text, for... and 
doesn't require
having such objs as part of the 'evas' api or as a dependency on such, 
nor deciding
on some abstract api or exported engine funcs.


 p.s. still have transforms patch on my list. just been dragged off into fixing
 some bugs and dealing with paid stuff for elementary. end of the month (start
 of next) definitely will get a bit of time i think! (just hesitant as this
 does break a few engines and that needs fixing)

   

   Transforms? I thought we were into stroked/filled, textured stuff 
already... :)

   As far as engine breaks.. well man, we knew that was inevitable - one 
way or
another. Problem is, there are so *many* engines people have been adding,
with a very primitive interface - we both knew this. It's going to take 
everyone
pitching in - or just forget about extending much of the gfx 
capabilities in any
real efficient way. :(


Click to find information on your credit score and your credit report.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3m2PcNwkpvcNdklpPRqCveOTlDZ5RGERkCyZzAVpVGtkOJMA/

-
This SF.Net email is sponsored by the Moblin Your Move 

Re: [E-devel] [Evil, svn trunk] autogen.sh failed on WinXP

2008-10-20 Thread Vincent Torri


On Fri, 17 Oct 2008, Lionel ORRY wrote:

 The dirtiest part of the patch is declaring eina_mempool_register and
 eina_mempool_unregister with EAPI, because it helps passing the link
 stage. I don't know much about the differences between .dll and .so
 (there must me many), but gcc was not happy with these functions
 prototypes. I don't know exactly how to correct that, it's just a
 workaround.

EAPI needs to be added in front of these mempool functions. I've also 
fixed the problem with ffs(). I have added an implementation for 
everything except cegcc (which already implements it). After the addition 
of EAPI, i think that eina will compile correctly with the latest Evil.

Vincent

-
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=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] terminal application based on the efl.

2008-10-20 Thread Jose Gonzalez
   I wrote:
 

What would be 'nice', and is doable now, would be the basics of 
 custom objs.
 ie. separately declared objs (ie. their apis) which the lib could load.. 
 even if their
 implementation would be much like what is done now and would still depend
 on knowing evas internals.
It'd be a step towards a more complete solution and gives the option 
 to later
 move such objs' implementation (if desired) to a true 'custom rendering' 
 one.
It would allow for such things as a 'cairo' obj (which could draw to 
 native update
 surfaces in some cases), for your text-grid, for funky text, for... and 
 doesn't require
 having such objs as part of the 'evas' api or as a dependency on such, 
 nor deciding
 on some abstract api or exported engine funcs.

   

   Just to give you a quick idea of what I mean by these evas object modules.

   First of all, we add ONE new engine function to get certain funcs for a named
obj type - this returns a void* which holds all the 'engine funcs' that a given
obj type will use. The lib will look somewhere for such named obj modules and
get this void* from the obj's 'engine-level' implementation (may need one per
engine backend).

   Then, say you want your text-grid obj with whatever its api. That's declared
in its own header file you need to include if you want to use this type of 
object.

   In the canvas-level implementation, say you have an Evas_Object_Text_Grid 
struct
which will contain its cur/prev states, etc.. but now also add a pointer to say 
an
Evas_Object_Text_Grid_Funcs, which are the 'engine funcs' for this obj type. 
This
will get assigned when you create an instance of the object by getting it from 
the
above mentioned new evas engine func.

   Then in the actual implementation of the obj's api funcs you basically do 
what
is done now (you have acess to evas internals - these are to be seen as direct 
evas
obect modules for now), and when you need to use an 'engine func' specific to 
the
object, well that's what you have in that Evas_Object_Text_Grid_Funcs pointer.

   So, we're just moving the new obj's api into its own header and have the lib
'load' the object's engine funcs (if any) which the canvas-level implementation
of the object's api will use as it needs.



Take a break - you deserve it.  Click here to find a great vacation.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nJgyAfHyvgCGRTUkMRokrAvNTzztt6rfJAlaE3CjmPQi2uw/

-
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=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] ecore: ecore_con_server_add() fails to unlink stale socket

2008-10-20 Thread Cedric BAIL
On Sat, Oct 18, 2008 at 2:02 PM, Shulga Nikita [EMAIL PROTECTED] wrote:
 Hi all,

 There is logic glitch in bind() error handling logic in
 ecore_con_server_add() implemented in  ecore/src/lib/ecore_con/
 ecore_con.c ( revision 36139 ), that results in  stale unix socket not
 being unlinked.

 Please take a look on following conditional:
if ((type == ECORE_CON_LOCAL_USER) || (type ==
 ECORE_CON_LOCAL_SYSTEM) 
(connect(svr-fd, (struct sockaddr *)socket_unix,
 socket_unix_len)  0) 
(unlink(buf) = 0))
  goto start;

 If type argument is equal to ECORE_CON_LOCAL_USER (i.e. first
 condition is true )  than rest conditions will not be evaluated, i.e.
 connect() and unlink() will not be called for socket in question. To
 ensure that   connect() and unlink() will be called if type either
 equal to ECORE_CON_LOCAL_USER or ECORE_CON_LOCAL_SYSTEM one should put
 parentheses around type checks. That is:
 ===
 --- src/lib/ecore_con/ecore_con.c   (revision 36772)
 +++ src/lib/ecore_con/ecore_con.c   (working copy)
 @@ -278,7 +278,7 @@
  }
if (bind(svr-fd, (struct sockaddr *)socket_unix, socket_unix_len)
  0)
  {
 -   if ((type == ECORE_CON_LOCAL_USER) || (type ==
 ECORE_CON_LOCAL_SYSTEM) 
 +   if (((type == ECORE_CON_LOCAL_USER) || (type ==
 ECORE_CON_LOCAL_SYSTEM)) 
(connect(svr-fd, (struct sockaddr *)socket_unix,
 socket_unix_len)  0) 
(unlink(buf) = 0))
  goto start;


In SVN, thanks for catching it !

-- 
Cedric BAIL

-
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=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [Fwd: Entrance problems]

2008-10-20 Thread Gustavo Sverzut Barbieri
On Sun, Oct 19, 2008 at 6:11 PM, Thanatermesis
[EMAIL PROTECTED] wrote:
 Hello Gustavo,

 I would like to tell you that there's a bug in entrance that does a
 black screen in the big percentage of computers with a X for mouse,
 after to see the commits and go back to the previous version of
 src/daemon/entranced_display.c , everything looks like to work perfectly

hum... could you point me which commit? And it would be better to mail
enlightenment-devel for such (in CC now)


 For now i will use this old version for my own usage (for the Elive
 package), but i should like that we can discuss about this in order to
 solve correctly the problem since your commits looks like to be for
 compatibility in hard-loaded or old systems, but by other side made an
 uncompatibility in others

 Do you actually maintain entrance ? i know that it doesn't has much
 development ;)

No, I just fixed that problem.


 PS: your email [EMAIL PROTECTED] is wrong, please update it on the SVN info

it's on purpose, it should omit my mail from web listings, that's how
it worked some time ago at least :-)

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

-
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=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] python-etk lists broken in rev 36540 (FSO testing on Openmoko)

2008-10-20 Thread yves mahe
Hi,

I just land here because I'm a Openmoko Freerunner owner (1 1/2 month)
and a python developper.

The FSO (freesmartphone.org) last upgrade and last image (18/10/2008)
bring me revision 36540 (svnr36540) of Enlightenment.

Now, python-etk lists no more appear, even with sample 15-list.py of
python-etk-samples. C example etk_test works as expected.

I don't know the origin of the problem and don't know what to do.
Do I have to file a ticket on FSO tracker or on Enlightenment tracker ?

Thanks.
Yves Mahe

PS : from where come this svn revision code ? Current revision code of
Enlightenment's svn seems to be slightly greater (36770) than 36540 (
http://downloads.freesmartphone.org/fso-testing/feeds/armv4t/python-etk_0.3.0+svnr36540-r0.1_armv4t.ipk
 

)


-
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=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [Fwd: Entrance problems]

2008-10-20 Thread Thanatermesis
The exact commit is:
http://trac.enlightenment.org/e/changeset?new=36417%40trunk%2Fentranceold=36364%40trunk%2Fentrance


Thanatermesis

2008/10/20 Gustavo Sverzut Barbieri [EMAIL PROTECTED]

 On Sun, Oct 19, 2008 at 6:11 PM, Thanatermesis
 [EMAIL PROTECTED] wrote:
  Hello Gustavo,
 
  I would like to tell you that there's a bug in entrance that does a
  black screen in the big percentage of computers with a X for mouse,
  after to see the commits and go back to the previous version of
  src/daemon/entranced_display.c , everything looks like to work perfectly

 hum... could you point me which commit? And it would be better to mail
 enlightenment-devel for such (in CC now)


  For now i will use this old version for my own usage (for the Elive
  package), but i should like that we can discuss about this in order to
  solve correctly the problem since your commits looks like to be for
  compatibility in hard-loaded or old systems, but by other side made an
  uncompatibility in others
 
  Do you actually maintain entrance ? i know that it doesn't has much
  development ;)

 No, I just fixed that problem.


  PS: your email [EMAIL PROTECTED] is wrong, please update it on the SVN
 info

 it's on purpose, it should omit my mail from web listings, that's how
 it worked some time ago at least :-)

 --
 Gustavo Sverzut Barbieri
 http://profusion.mobi embedded systems
 --
 MSN: [EMAIL PROTECTED]
 Skype: gsbarbieri
 Mobile: +55 (19) 9225-2202

 -
 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=100url=/
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

-
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=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] python-etk lists broken in rev 36540 (FSO testing on Openmoko)

2008-10-20 Thread Gustavo Sverzut Barbieri
I got your last mail as well, just need some time to work on it. but
maybe other guys can take a look before me.

On Mon, Oct 20, 2008 at 11:04 AM, yves mahe [EMAIL PROTECTED] wrote:
 Hi,

 I just land here because I'm a Openmoko Freerunner owner (1 1/2 month)
 and a python developper.

 The FSO (freesmartphone.org) last upgrade and last image (18/10/2008)
 bring me revision 36540 (svnr36540) of Enlightenment.

 Now, python-etk lists no more appear, even with sample 15-list.py of
 python-etk-samples. C example etk_test works as expected.

 I don't know the origin of the problem and don't know what to do.
 Do I have to file a ticket on FSO tracker or on Enlightenment tracker ?

 Thanks.
 Yves Mahe

 PS : from where come this svn revision code ? Current revision code of
 Enlightenment's svn seems to be slightly greater (36770) than 36540 (
 http://downloads.freesmartphone.org/fso-testing/feeds/armv4t/python-etk_0.3.0+svnr36540-r0.1_armv4t.ipk

 )


 -
 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=100url=/
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel




-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

-
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=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] Environnement de bureau - Wikipédia / Desktop environment

2008-10-20 Thread Michel Briand
Hi all,

shall E deserve a word in these pages :

http://fr.wikipedia.org/wiki/Environnement_de_bureau

http://en.wikipedia.org/wiki/Desktop_environment

Cheers,
Michel


-
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=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] Found a small issue when compiling from today's SVN

2008-10-20 Thread M.McNeil
Hi,

I'd like to post a problem ( and solution ) that I found while trying to
update my e17 installation today on Ubuntu.  I use the easy_e17.sh
script ( of course! ), and while embryo was trying to compile, make kept
complaining about not being able to find eina_types.h.  I fixed this by
changing the following:

in embryo_private.h, line 33:

#include eina_types.h

to

#include eina-0/eina_types.h

I then changed embryo_cc_sc.h, line 39:

#include eina_types.h

to

#include eina-0/eina_types.h

I apologize if my message is lengthy, but I thought you all would want
to know.

Thanks,

Mike

-- 
-

Mike McNeil

Sr. Network Engineer

Information Systems and Technology

University of California Berkeley



-
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=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: urandom trunk/E-MODULES-EXTRA/forecasts

2008-10-20 Thread Gustavo Sverzut Barbieri
On Mon, Oct 20, 2008 at 7:28 PM, Enlightenment SVN
[EMAIL PROTECTED] wrote:
 Log:
  unswallow the icons, or there will be visible duplicates, even if the gadman 
 window is hidden.
 +if (swallow)
 +  {
 + edje_object_part_unswallow(inst-forecasts-forecasts_obj, 
 swallow);
 + evas_object_del(swallow);
 +  }

you don't need to unswallow if you del, that's automatic.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

-
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=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel