On Thu, 1 Mar 2007 22:55:29 -0300 "Gustavo Sverzut Barbieri"
<[EMAIL PROTECTED]> babbled:

> Hello,
> 
> I'm still getting used to Edje/Evas, read some nice documents from
> website and wrote some test edje files.

note - if you can wait - we can go over this in person next weekend - i'll be
there in recife (porto del galinhas) next weekend (i should arrive in recife
about midday on saturday). i'll be at the open bossa conference until thursday.

> I work at http://openbossa.indt.org/canola/ and we plan to use
> Evas/Edje there, but as everything have a begining, I still need to do
> some tests and check what is possible and what's the best road to some
> achievements.

absolutely. next week i can show you my rage "rewrite" (i'm tentatively calling
it "rage - hd" it's still rage, can play low res videos on low res output
(800x600 or so) but is also intended to scale up to full hd 1920x1080 or more -
it already does, but i'm just tweaking the UI to be able to  deal with both
ends of the video spectrum and anything in between). i like what you have with
canola there - looks nice. i think evas + edje etc. can do everything you have
there so far, and more. performance is going to be the only issue you are going
to really need to worry about. that is going to be very much tied to the
rendering engine if you don't do "silly things" in evas object land :)

> We basically present small amount of items and change them a lot, this
> need to be fast, with animations. Basically it's a vertical list of
> text strings and we hope to present a thumbnail view with a 3x2 grid,
> also moving vertically.

do you really need to have a fixed view of 3x2? why not use some form of table
layout. edje can't do generic layouts (like lists, tables, etc.) yet - i want
to add some of that eventually, but in a very generic way (so you can have wavy
lists for example)

> Since device's memoy is low, we hope to just render text strings to
> images when they're visible. Same for images/thumbnails... So creating
> one Evas object for each item, keeping them offscreen and them moving
> then is a no-goal :-(

why render text to images at all? just use evas text objects (or even better
abstract it in edje as a text part and let the designer decide how the test is
to look and where it is laid out within an element - what kind of padding,
design etc. is around it etc.). evas objects are low on resource needs. a basic
object uses about 240 bytes of ram (last i did a check - 32bit architecture).
image objects also incur an extra 144 bytes for image specific info (then add
in strings for file paths needing to be stored - but all in all its going
to be well under 512bytes). text objects get an extra 100 bytes on top of
the basic object overhead plus strings for the text content, font name etc.
(evas shares all string tokens between all objects whenever it can so if
you set the same text 1000 times evas only ever has 1 copy of the string).

image objects don't use much more for the basic object UNTIL they need image
data. image data is loaded "on demand" the first time evas actually needs the
image data and stored as argb32 (4 bytes per pixel of source image - the actual
image size in the canvas does not affect its memory usage, only the source image
dimensions will determine memory usage). evas doesn't currently "page" images
to and from the source to try keep memory usage down, but this is perfectly
possible - i have considered doing this, but haven't had a need for it yet. if
you are very concerned you may run out of memory we can talk this over and add
a "working set" mem option where evas will try and keep all image (and font
data) that it can actually page from files within a certain working set (evas
will also need memory for temporary rendering buffers - these get allocated on
the fly as needed - but the worst case is a buffer for the whole canvas).

anyway - that was probably more information than you needed :)

> My initial idea is to build items N+2 rows of items in edje, items
> relative to their top sibling, with two state: "default" being the
> initial position, "top" when it move up, "bottom" when it move down.
> The extra 2 rows are used to do animations (one above and the other
> below). Then, in C, I would change text or image contents and trigger
> state change.
>    Animations would be a vertical move (transition sinusoidal), just
> to make it be smooth and pleasant.
> 
> Am I right to follow this path?

ok - here is an interesting point. it's a design decision. if you want a FIXED
menu that only ever has these elements - then this will work, but it doesn't
adapt very well as i mentioned above. one day i want to be able to have edje be
able to do at least some generic layout stuff (lists, tables, flow layout etc.)
but done differently to widget sets that tend to have regular non-overlapping
layout. i want to tackle this with some way for the edje to define a layout
algorithm and geometry so you could have lists that wiggle down the screen and
items change in size based on their position in the list, the scrolled state of
the list and their other states (selected, hilighted, disabled etc.) this will
also involve edje being able to load/swallow and arrange other edje elements -
but for now i am putting this off as a future enhancement. until then you
either have some kind of fixed layout where the edje can swallow N items (you
need to do the swallowing in code) and edje then just arranges the N swallow
regions, or you need to create a smart object that arranges items for you (like
e17's e_box for example - it's a horiz/vert box layout). smart objects are like
custom widgets in a widget set - you basically provide some basic evas methods
for the smart that get called when its moved/resized etc, and then in these you
modify the smart child objects as you need based on your layout policy..

> I plan to write some small apps for Maemo/Nokia 770/N800 in order to

or you can just write it for your desktop to make the dev cycle faster :) build
every now and again for your target (770/800) :)

> experiment. My first would be a thumbnail previewer, then a list with
> a music player... this way I do simple, yet useful, applications, test
> my skills, check some bootlenecks before we start to do things in
> Canola itself.

for performance - definitely need to run and build on the target, but for
learning and playing with ideas - locally on your pc is a fine way to do this :)

> Thanks!
> 
> -- 
> Gustavo Sverzut Barbieri
> --------------------------------------
> Jabber: [EMAIL PROTECTED]
>    MSN: [EMAIL PROTECTED]
>   ICQ#: 17249123
>  Skype: gsbarbieri
> Mobile: +55 (81) 9927 0010
>  Phone:  +1 (347) 624 6296; [EMAIL PROTECTED]
>    GPG: 0xB640E1A2 @ wwwkeys.pgp.net
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> enlightenment-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    [EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to