Re: [E-devel] patch: Evas fill policies

On Wed, Apr 30, 2008 at 7:59 PM, Jose Gonzalez <jose_ogp <at> juno.com> wrote:
>
>
>  > As we discussed at IRC, probably this policies can be handled on top
>  > of currently existing Size_Hints and no other members should be added
>  > to the struct.
>  >
>  > Also agreed at IRC is that most difficult part is to get all the
>  > requirements written, we should start with V/HBox as they're useful
>  > and easier to write. We'll do this in wiki (with you sending the URL
>  > as soon as you get it started!).
>  >
>  > We need to figure out what hints to use, if they will be enforced or
>  > not or depends (configurable) and how to act when layout object
>  > (parent) geometry is larger or smaller than the requested/possible by
>  > the children and also the same about children within space when in
>  > homogeneous mode.  A list would be:
>  >
>  > Hints to use (first draft):
>  >    - min = max = request => no expand/fill
>  >    - max = request = infinite => expand
>  >    - max = infinite => fill (?)
>  >    - maybe add more values for aspect_mode?
>  >
>  > How to lay out children within the self geometry:
>  >     - {v,h}align from 0.0 - 1.0 to align the box composed of all
>  > children objects and spacing/margins. If children+spacing box is
>  > larger than current geometry it would overflow to the other side.
>  > ie: halign = 0.0 (left) would overflow to the right.
>  >      - maybe consider -1.0 a value to "spread" (like text's

Re: [E-devel] Evas object modules

   I wrote:

>       There's a very simple way to have this ability in evas right,
> one that requires very few internal additions and no modifications
> to any of the current stuff.
>   

      That should've read "...to have this ability in evas right now,"
Note that this deosn't mean that implementing any particular new obj
type would be easy (some may, most won't), just that there'd be an
simple mechanism for adding such new object types, ie. of extending
evas in this way.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Re: [E-devel] patch: Evas fill policies

   Gustavo wrote:

>>       One of the things I see going on with this kind of thing is
>>  an attempt to put more and more 'widgetry/layout' kinds of needs
>>  into evas objects in a generic way. The 'problem' with some of this
>>  is that evas objects don't have any real notion of 'inheritance' or
>>  other sub-typing mechanism, and putting more and more of this into
>>  evas in a generic way, though it's useful for many, many kinds of
>>  things, also presents a potential source of 'issues', confusion,
>>  conflicts, etc.
>>     
>
> Just to make clear: what goes into Evas_Object is the hints. They
> could be represented as allocated structs managed with
> evas_object_data_*(), but since they're so common we could 1) make it
> more standard, helping integration and 2) minor optimizations by not
> walking the linked list doing strcmp() in order to find these values.
>  The integration idea came out after the layout stuff appeared and it
> would duplicate lots of stuff into edje, thus having this would help.
>
> All this layout stuff will not go inside evas, but some other library,
> either a new one or esmart.
>
> Also, layout is not widgets, but they can be used to provide widgets.
> They're regular smart objects that will be provided to avoid code
> duplication and help integration. Also, by making it like that and
> using standard properties (size hints) we can expose it from Edje
> without much trouble.   The big picture is to have this and enable
> toolkit integration one day, like be able to mix in the same vertical
> list a rectangle, an etk button and a ewl list, this would be really

[E-devel] More aggressive packing of Evas_Object

Hi guys,

As you can see from CVS log, I did some repacking of Evas_Object and
managed to save more than 80 bytes, almost 1/3 of it is gone.

While some aggressive packing went in, like "layer" number being a
short now, I'm a bit unsure if applying the attached patch is a good
thing. It will save 4 bytes from cur,prev, so it's 8 bytes in the end,
but the solution is a bit ugly, as the members
cache.clip.{visible,dirty} now are cache_clip_{visible,dirty} so it
can be packed with the other bitfields. On one hand it saves memory,
on the other it's ugly as hell :-P

Apply or not? that's the question...

PS: please test Evas on as many
machines/architectures/compilers/operating systems as possible to see
nothing is broken by these patches! It relies on compilers working
fine with bitfields.

--

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi
Embedded Systems
--------------------------------------
MSN: barbieri <at> gmail.com
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010

Re: [E-devel] More aggressive packing of Evas_Object

> As you can see from CVS log, I did some repacking of Evas_Object and
> managed to save more than 80 bytes, almost 1/3 of it is gone.
>
> While some aggressive packing went in, like "layer" number being a
> short now, I'm a bit unsure if applying the attached patch is a good
> thing. It will save 4 bytes from cur,prev, so it's 8 bytes in the end,
> but the solution is a bit ugly, as the members
> cache.clip.{visible,dirty} now are cache_clip_{visible,dirty} so it
> can be packed with the other bitfields. On one hand it saves memory,
> on the other it's ugly as hell :-P
>
> Apply or not? that's the question...
>
> PS: please test Evas on as many
> machines/architectures/compilers/operating systems as possible to see
> nothing is broken by these patches! It relies on compilers working
> fine with bitfields.

I'll try on windows with mingw. Indeed, i've forgotten to add 
-mms-bitfields in the compilation flags in the efl, which is needed if 
other programs use evas and are compiled with ms vc++ if i'm not mistaken. 
See:

http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00253.html

There is a description of that flag

Vincent

Re: [E-devel] More aggressive packing of Evas_Object

   Gustavo wrote:

> Hi guys,
>
> As you can see from CVS log, I did some repacking of Evas_Object and
> managed to save more than 80 bytes, almost 1/3 of it is gone.
>
> While some aggressive packing went in, like "layer" number being a
> short now, I'm a bit unsure if applying the attached patch is a good
> thing. It will save 4 bytes from cur,prev, so it's 8 bytes in the end,
> but the solution is a bit ugly, as the members
> cache.clip.{visible,dirty} now are cache_clip_{visible,dirty} so it
> can be packed with the other bitfields. On one hand it saves memory,
> on the other it's ugly as hell :-P
>
> Apply or not? that's the question...
>   

      Hey man, I hope you didn't think my remarks about adding
properties and such had to do with object sizes... It was more
about having all these things (including some older stuff) that
may or may not apply to this or that obj type, no way to know,
etc. Ideally a "pie in the sky" kind of thing would be an evas
based on an ecore_object 'object' system (with all the ecore gui
stuff, including ecore_evas, split off from an ecore base), and
similar utopian ideals. :)

      Anyway... although I'm not sure just how 'important' it is
(in practice) to have object sizes cut down as much as you managed,
that's nice work anyhow! But yeah, some of it is a bit 'ugly'...

[E-devel] Problem to differentiate left and right win keys

Hello,

Using e17 for several days now, I want to customise some keyboard
shortcuts.

As control and meta keys interfere with some applications (Emacs )
I want to use the left (keycode 115) and right (keycode 116) win keys.

I assigned Super_L to the left one and Super_R to the right one but in
the short cut configuration tool they both appear as WIN keys.

It's like e17 use keycode and not keysym, if so, is it possible to use
keysym for keyboard configuration?

Regards.
--

-- 
Daniel Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

_______________________________________________
enlightenment-devel mailing list
enlightenment-devel <at> lists.sourceforge.net

[E-devel] Nightly build log for E17 on 2008-05-01 07:08:50 -0700

Build log for Enlightenment DR 0.17 on 2008-05-01 07:08:50 -0700
Build logs are available at http://download.enlightenment.org/tests/logs

Packages that failed to build:
enna  http://download.enlightenment.org/tests/logs/enna.log
epdf  http://download.enlightenment.org/tests/logs/epdf.log
evolve  http://download.enlightenment.org/tests/logs/evolve.log

Packages with no supported build system:
entice, esmart_rsvg, exorcist, python-efl, 

Packages skipped:
camE, ecore_dbus, engage, enotes, enscribe, epbb, eplay, erss, etk_server, 
etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, 
ruby-efl, webcam, 

Packages that build OK:
alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore_li, ecore, edata, 
edb, e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, eflpp, efm_nav, 
efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, 
emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, 
enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, 
epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, 
etk, etk-perl, evas, evfs, ewl, examine, execwatch, exhibit, exml, expedite, 
express, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, iiirk, 
imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, 
mixer, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, 
rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, 
winselector, wlan, 

Re: [E-devel] More aggressive packing of Evas_Object

On Thu, May 1, 2008 at 4:18 AM, Vincent Torri <vtorri <at> univ-evry.fr> wrote:
>
>  > As you can see from CVS log, I did some repacking of Evas_Object and
>  > managed to save more than 80 bytes, almost 1/3 of it is gone.
>  >
>  > While some aggressive packing went in, like "layer" number being a
>  > short now, I'm a bit unsure if applying the attached patch is a good
>  > thing. It will save 4 bytes from cur,prev, so it's 8 bytes in the end,
>  > but the solution is a bit ugly, as the members
>  > cache.clip.{visible,dirty} now are cache_clip_{visible,dirty} so it
>  > can be packed with the other bitfields. On one hand it saves memory,
>  > on the other it's ugly as hell :-P
>  >
>  > Apply or not? that's the question...
>  >
>  > PS: please test Evas on as many
>  > machines/architectures/compilers/operating systems as possible to see
>  > nothing is broken by these patches! It relies on compilers working
>  > fine with bitfields.
>
>  I'll try on windows with mingw. Indeed, i've forgotten to add
>  -mms-bitfields in the compilation flags in the efl, which is needed if
>  other programs use evas and are compiled with ms vc++ if i'm not mistaken.
>  See:
>
>  http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00253.html
>
>  There is a description of that flag

hum, I doubt that will matter because all the structs are internal to

Re: [E-devel] More aggressive packing of Evas_Object

On Thu, May 1, 2008 at 5:11 AM, Jose Gonzalez <jose_ogp <at> juno.com> wrote:
>    Gustavo wrote:
>
>  > Hi guys,
>  >
>  > As you can see from CVS log, I did some repacking of Evas_Object and
>  > managed to save more than 80 bytes, almost 1/3 of it is gone.
>  >
>  > While some aggressive packing went in, like "layer" number being a
>  > short now, I'm a bit unsure if applying the attached patch is a good
>  > thing. It will save 4 bytes from cur,prev, so it's 8 bytes in the end,
>  > but the solution is a bit ugly, as the members
>  > cache.clip.{visible,dirty} now are cache_clip_{visible,dirty} so it
>  > can be packed with the other bitfields. On one hand it saves memory,
>  > on the other it's ugly as hell :-P
>  >
>  > Apply or not? that's the question...
>  >
>
>       Hey man, I hope you didn't think my remarks about adding
>  properties and such had to do with object sizes...

of course no, but having almost 300 bytes for each object was
something I don't like for a long time. I just have some spare time
and went to the code and fixed what was easy. As you can see there is
not much we can do other than that in EVAS, but if you look at Edje...
oh god! With part descriptions over 300 bytes I wonder how we can be
so much lighter than GTK for example (and yes, we are a lot lighter
than, ie matchbox).