I have a question for you on this though: I imagined having
'native surface' image obj api given in each of the engine headers,
but you added a generic evas api for it.. What exactly do you have
in mind here? eg. say with gl-textures?
literally evas exposing the engine drawing routines
Gustavo wrote:
We were discussing about this idea at IRC and the summary is
written at:
http://wiki.enlightenment.org/index.php/Evas_Object_Size_Hints
Idea is to move this common requirement to Evas_Object so it can be
shared by toolkits, Edje and even the layout smart
Also, how can one 'set' an object's min/max size? Wouldn't
these be intrinsic to the object?
_
A cleaner home is just a click away. Click now for great housekeeping services!
Gustavo wrote:
On 2/27/08, Vincent Torri [EMAIL PROTECTED] wrote:
I think that we should add evas filters. It should be very
interresting for student (study of the internal behaviour of
evas, interresting algorithm to perfmorm different filters...).
Rotation
Ravenlock wrote:
What has to happen is, we have to describe our ideas in terms
that non-E-devs can understand, and appreciate.
(Nice work on this BTW)
Ok, let's take a naive point of view - we're all now neophytes
with no real knowledge of e, and someone's asking
Vincent wrote:
* writing an evince-like prog in full edje
Why would anyone not familiar with e care about anything like
this? There's already an evince. Why would a similar app, but with this
edje, be of any interest to anyone, or of interest enough that they'd
pay someone to
Vincent wrote:
what i wanted, is a gui that is not like evince and use the power
of edje (see the wiki)
With your reasonning, just gave up all the EFL, as they are libs
to write mainly gui. And a lot of tool already exist using gnome
or kde.
Indeed, unless you can
Ravenlock wrote:
First, lets get in the correct mindset. We are not asking people
to help with our E stuff. The goal of SoC is to help students
learn and to create more open source code. Google is not putting
up bounties for things *we* want done. Google is gonna pay a few
Ian wrote:
Alright I've taken this summer of code research a bit further
apparently we're not blacklisted in anyway. The reason we were not
accepted last year is that our application was a bit suboptimal
and the ideas list was poor we didn't elaborate enough on the
ideas what they
this would violate the principle of least surprise.
Well said. U... then again, setting a size load option
on an image and getting -- surprise! it may or may not be what you
asked for! does seem to flaunt that excellent principle you want to
adhere to. :)
PS.
Not to
Vincent wrote:
I think that we should add evas filters. It should be very
interresting for student (study of the internal behaviour of evas,
interresting algorithm to perfmorm different filters...).
Rotation, perspective, reflection can be a good beginning and
maybe add
Michael wrote:
about these suggestions, would it be interesting to add them in
the trac main page ?
My point is that I think suggestions might be jumping the gun
a bit, unless the sheer volume of suggestions might help reverse
our previous poor fortune.
Step #1: Get accepted
Jess wrote:
Is there a dedicated person we should send the email to?
Or just email the list? Sorry, not familiar with the etiquette here.
For greater exposure, feedback, etc. the list here would
clearly be best.
This is something that people here have to build
thanks for the tip will give it a try. But there is still
the issue that the function documentation is wrong. Therefore
It could be that the hsv_color_range function is expecting
different values.
Ok, took a quick look, and... Yeah, that whole imlib2 grad
implementation is screwed..
Gustavo wrote:
Now to Evas part: we have an outdated DirectFB which AFAIK nobody
is using or willing to maintain and we (more specifically Cedric)
have SDL almost integrated.
The directfb engine was initially written a long time ago
and was never kept up with as much as other
As for implementation details, smart object is not the best option,
actually using Evas as WebKit backend is not the best option around.
...
...
So the best option is to draw to some buffer and use this as image
data, then take care of event passing to this webkit engine. Using
...
there were no specifics on why we were denied beyond a vague
we don't think you are a worthy/valid/interesting open source
project.
That would be their right to decide of course, and a natural
view for them since e has so-far shown little interest in web related
'technologies' whereas
Cedric wrote:
If understood the code correctly, when I change a property that
could affect the layout of the edje, _edje_calc is called directly
instead of being defered until render like all native evas_object
behaviour. That's because smart object don't have a render_pre
function.
- call _edje_calc only from a render_pre.
I should add though that in this particular case, there could
be potential 'side effects' in event handling.. because, some changes
of state that could be affecting the size and positioning of things,
would then be deferred to render_pre time,
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
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; /*
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
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
Nathan wrote:
The answer is yes and no. You can certainly do this simply by
mapping the theme for a widget to your Edje. The problem is that
Is mapping the theme for a widget to your Edje a standard,
well-known thing to do in ewl? Is that the same as using one's own
edj file
Just to get back to this a bit...
Gustavo wrote:
I can provide you some tips tricks others told me along the last
year. My first advice to you, based on my own experiences and
those from my team and people I introduce to EFL: don't overuse
Edje and mainly Embryo. Everyone
There are some documentation bits here and there.. eg. the
wiki at http://wiki.enlightenment.org, but I don't think I've ever
seen any docs on embryo at all (it's kind of an incomplete
scripting language as it stands, and likely mostly raster has any
real insight into it).
Gustavo wrote:
on a self-marketing side: I wrote the Python-EFL bindings,
we built Canola2 (http://openbossa.indt.org.br/canola) on top
of it and it works really well, if you know python, or is fine
with learning a new language, I really recommend you to do,
life will be a bit
Modified Files:
e_widget_frametable.c e_widget_frametable.h
Log Message:
Add const to frametable's label.
Just a minor thought here on all this widgetry stuff...
For all of these 'e_widgets', wouldn't it be better to have
a consistent interface for 'adding' them
Gustavo wrote:
I have no time to reply your mail as detailed as I would like,
but one idea to do what you want is to make the gadcon usage
recursive. Then we could have an object that exports its own gadcon
api to children. Maybe it's an overkill and can be done by means
similar to
Again, I'm just proposing a simple mechanism to enable
the notion of loadable, themable 'evas-objects', so that these
interesting, compound, gadget-like things can be made available
for use/re-use on a wider basis.
There are a LOT of interesting 'objects' one can make
Sometime back, Gustavo wrote:
So, my idea is either to provide larger shelf size or provide
another shelf category, maybe desktop applets, that could be
placed everywhere (if it makers hard to efm icons, then maybe
disable those or make this new shelf attached to borders, with
icons
Gustavo wrote:
Has anyone followed up on this? It seems to me that this
could be easily done in a way that would allow for a certain amount
of re-usability of such 'gadgets', and yet enough flexibility to
have custom designs as well. Likely there are multitudes of ways to
Is there any internal call to do these scaled blits or just
those of evas_common? If so, those more used to it: there is
any way to use these evas_common functions to do this convertion?
Only the 'common' functions for scaling are really needed.
Just do an imitation of what the e17
What: Gareth from SCALE has really kindly offered Enlightenment.org
(that's use guys) free floor/booth space @ SCALE ( http://www.socal
linuxexpo.org/ ) Next February (2008). So it looks like I will be
there. Also Nathan of EWL fame and work will likely be there.
Is there anyone else in the
I can make it there if need be.
why don't you come just to hang out - since you're there :)
I'm quite far away actually, so while that would be nice, it's
not something I'd really consider all that lightly.
_
Click to
Man, we all say some silly things in time, but this has to be one
of the good ones from you. :) It's a 'load option' so it's fine
for this to be 'optionally' implemented in a loader? Wow!
correct. load options include things like DPI settings. do you
expect every loader to now scale
I have been working on some little improvement for Edje recently.
The first patch, edje_data_file.diff, add support for a
data.file entry inside edc file. It give the possibility to put
text file inside edje directy.
hmm - ok. sounds ok to me - using that for copyrights and such?
Carsten wrote:
Unless... Oh, oh.. unless we didn't finish off implementing
the load-size option for all loaders. I know we did it for the
svg loader, and that the jpg loader respects loading scaled-down-
by-dyads, but I can't recall if we really did finish off making
sure
Carsten wrote:
At the very least, it should be a negotiable process where
clients can specify the result formats they can support and
the thumbnailer can select from those supported formats.
A fallback requirement of png or some other standard format
would be reasonable.
Dave wrote:
For all of you that like desktop effect ala compiz there is a good
news.
I make some works on the old bang module, if you don't know bang is
a compiz derivate packed in e module. So a module that do composite
using OpenGL. :)
.
This might actually
Cvs, svn, git, twit,... It's all weird mojo. Maybe Michael could
write an eterm 'module' of some sort that would feature nice,
friendly, easily understood commands for interfacing with any of
these - ones where it doesn't matter which one is really being
used.
Vincent wrote:
before putting that in bugzilla, here is what I obtain with the
following code:
[code]
o = evas_object_gradient_add (evas);
evas_object_gradient_fill_angle_set(o, 90);
evas_object_gradient_fill_spread_set(o, 1);
evas_object_gradient_fill_set(o, 0, 0, w,
A last topic I would like to discuss is FPU need by Edje.
Right now without hardware floatting point, Edje could loose
around 30% of time in soft float when you have many objects
on the screen. I don't know what would be the best solution to
this problem, doing some fixed point
Dave wrote:
Hi all,
I'm in trouble with the evas event system :(
Working on esmart_container to make an iphone-like scrolling list
(with friction) this is the situation:
I have a trasparent evas_object (big as all the container) used
to grab mouse events. When you click drag the
I should add that I hope you suceed with this effort, one way
or another. An edje-editor is a very important thing to have, and
should be a top priority for an efl based project.
I'm curious though.. What do other 'WYSIWYG' editors that deal
with similar doc based things do? eg,
Dave wrote:
Hi all,
Just two words to make you inform the new edje_editor status.
I have now reach a first stable version of the patch to edje
(bugzilla #294). In my opinion this version is ready
to be committed to the edje cvs, but I didn't get any devs
opinion :(
At
One thing that isn't really dome in e, but could be, is to
let edjes that correspond to backgrounds provide 'largesmall'
thumbs in the edje itself.. ie. have two additional groups, say
thumb_large and thumb_small, that give a (tweened) image
representation of the thumnailed main
he have to cvs add it, not available in some cases (anoncvs).
He's a developer. He doesn't use anoncvs.
Also, having an weird interface that nobody uses it make it suck,
see?
Sorry, but there's nothing weird about diff -Nu since it's exactly
the same options normal diff takes.
Nathan wrote:
I don't think there's a need to require that 'thumbnailing'
must involve a specific means for storing some standard image
format somewhere.. one may not want or need to store anything
...
At the very least, it should be a negotiable process where clients
Nathan wrote:
1. Split thumbnail generation into pluggable processes. If we can
specify external commands for generating thumbnails, we reduce the
amount of code necessary to support new formats. This also gives us
robustness when a dependency mis-behaves and crashes the thumbnailing
I wrote:
For jpgs you don't have to worry about it since we only
deal with rgb images then, hence there's no difference (and no
premul or un-premul takes place). It does matter for pngs with
alpha though, and then it's fastest to deal with pngs embedded
in eet. But I think the
I wrote:
I looked at e_thumb_main - it saves to eet files directly.
That's not really sufficient for giving flexible thumbnail-file
saving functionality for others to use - it's just too restrictive
...
Having said that, I also just took a quick look at epsilon..
and
I wrote (regarding raster's thumb),
It seems to have an evas-object interface that abstracts away
the 'thumb file' concept and just concentrates on giving you the
display-object you want for a given input 'uri' and desired size
(probably could give more info as well).
Depends. If you're already using evas, and want to load
and save image files to smaller sized (thumbs) versions, then
using evas rather than going thru imlib2 could be faster -
certainly for jpegs. Maybe for pngs, *if* you're saving to eet.
Evas premuls all loaded non-premul argb
As raster mentioned, and as I believe, the best thing for epsilon
would be a rewrite using evas instead of imlib2... something
extremely similar to e_thumb. Raster said that if this did occur,
e would likely change to using epsilon as well.
If epsilon is still using imlib2 for
- how expensive is evas/ecore_evas_buffer in comparison to imlib2
to generate thumbs;
You don't need ecore_evas_buffer to generate 'thumbs' of
jpg/png/svg, that's only for generating smaller views of a 'general'
evas canvas rendering. For example, if you want to show a live thumb
Gustavo wrote:
- how expensive is evas/ecore_evas_buffer in comparison to
imlib2 to generate thumbs;
You don't need ecore_evas_buffer to generate 'thumbs'
of jpg/png/svg, that's only for generating smaller views of a
'general' evas canvas rendering. For example, if
Michel wrote:
On the 3D topic, I've read in this list that many people want
to keep away from 3D rendering. I've no problem with that.
But improving the 2D rendering with some tricks using GL is
the sort of things I'd like to contribute to ;o))).
As to the gl and 3D
Michel BRIAND wrote:
...
I'm skilled in
...
-3D scene graph and rendering with OpenGL
...
I like very much the E config scheme that Raster ask me to
look into recently...
Raster asked you to look into E config.. as opposed to maybe
getting the evas gl engine working
One 'problem' with an edje api for getting/setting properties
is that it exposes edje's internal structure more and more.. which
may or may not be desirable.
The api I have in mind don't have this exposure problem:
I don't want to return pointer to the internal structs,
but only the
I wrote:
Isn't what you're after (in full) something akin to a 'DOM'
kind of capability for edje/edc? I believe Brian and Chady had
expressed an interest in this at some point as well.
Just to add a bit to that.. Hisham had also expressed a
similar interest as well. For
I wrote:
Things like edje-editor and evolve could've been much further
along if these kinds of issues weren't there.. and it's where having
used already existing tools for 'edje' could've helped.
One could have other formats/scripts as inputs to create
eet-encoded .edj
Yet one more bit here (as I slowly regain my E memory),
One other thing of relevance here is the notion of styling.
Just as xml based formats like xhtml, svg, ... allow for styling
via css, ie. allow for one to vary certain values of properties of
a 'src document' (but not the
Michael BRIAND wrote:
LOL
it's a sort of dangerous journey... being stuck into a words
demonstation like this...
Not at all. I know that KainX is just extremely rigorous
and demands a lot from himself -- and others. He showed me that
he did indeed know what he was talking
Dave wrote:
Nothing more for now as this require some addition to the edje
library and first I want to hear the voice of the mantiners:
This is the first stub I have done of the new api
I'm not one of those voices, but there's something curious
here.
Michael wrote:
So, either I misread your intended meaning, or you've
misread mine. You decide. :)
You misread mine. Of course was used as a conjunction, nothing
more. I could have said however or but then or any number of
others. Had I meant of course as a way to agree with
Morten wrote:
What does HTH, mean?
Hope That Helps
Ahh, thanks. I kept seeing things like Hitting The Hay,
Higher Than High, Hotter Than Hot, Humping The Hippo, ... ?
and was having problems visualizing Michael and the ...
(just kidding MJ. :) )
Michael wrote:
It does sound a bit hypocritical. I would disagree with both
you and Simon on this.
But my only point was that he was being hypocritical, so you can't
agree with me and then disagree with me. That makes *you*
hypocritical. :)
Well, not quite. You did
If the desktop (and/or fm) component can do whatever it now
does with icons, and whatever else it does with gadgets, then
why can't it do anything with whizblings? Or with wambots, or
with . ?
you can. its a few trivial lines of module code to go put any evas
object on the
Michael wrote:
There is no good reason to have three different toolkits in
the same project,
Of course, this is what a lot of other people said about Etk back
before it got thrown in CVS. So now you sound hypocritical.
It does sound a bit hypocritical. I would disagree
Simon wrote:
I hope that everyone can be just as excited. I know I am.
I smell a new age of... Enlightenment. :) :)
I'm really excited about this too! Especially about the new
communication plan! I actually even think we should do more on
the communication point. It would be
That last email:
so what you want is me to simply say yes yes - do whatever you
want
...
No, I want you to put on a big E logo outfit and dance around
and the next/first e rave. But that's just me.
Anyway, let's leave this. Concentrate instead
Hisham wrote:
As I have talked to both, a lot, about this matter, I'm starting to
develop a feel to the true issue here.
.
The 'problem' here is actually deeper than some of what you
mention Hisham.
Imagine for a moment that you try to build something like an
Hisham wrote:
mailing list / #edevelop and off) share your same opinions.
So, whats next?
I don't know what's next - we're ALL going to have to
determine that.. Carsten proposed some very good steps in his
initial email.
But I do know what's first: It's to get these
Carsten wrote:
I'll keep this short, since I really don't want to prolong
this sub-thread between us.
Busy or not, you've never expressed any interest or support
for seeing this project become a true community one.
i have done just he opposite - i have encouraged
Carsten wrote:
First.
I need to offer some big apologies. I have been pretty bad at being
.
Well, I'll give you my own thoughts on this.
These new developments in E may well be exciting new
opportunities and whatnot, but for some e-developers at least,
Gustavo wrote:
so, how to speed up text rendering? raster suggested me to create a
render cache so scaling, font and etc would be cached and maybe ...
There are several basic ways, associated with 'caching',
by which drawing styled text could be optimized.
1. At canvas
about that, why not doing a branch in cvs ? Branches exist for
that kind of stuff.
a perfectly sane idea. we use branches rarely - but this is a case
where it would be good. we should add jose to the cvs access/devs.
jose - if you want, send me your ssh public key (id_dsa.pub in
~/.ssh)
Gustavo wrote:
I want to know how difficult would be to implement support for clip
using gradient objects.
...
...
We are willing to implement it if you give us some hints :-)
Just thought I'd go back to this a bit here, and see if
I can give you an idea of what's
The way Carsten setup clip-object semantics in evas is
that any object can clip any other, and this can be arbitrarily
iterated (since a clip object can have a clip object as well).
Also, an object can clip any number of objects.
right now clip is all about rectangle operations to
I wrote:
Let's take your example of an 'evas_object_transform_set'
api function that you want.
Ok, when you come to actually implement this, you will add
some 'transform' to the evas object structure so that all objects
keep the transform state. Then, when the canvas
Gustavo wrote:
Great you're already doing it, at least it will serve as reference
if not integrated/used... is there any CVS/SVN/GIT/... we can follow
and do some testing?
None except my local copy.. and as it's partly working, partly
in the process of being worked out..
Carsten wrote:
personally, as an intermediate-step i'd like to simply be able to
modify the FILL of an image (or text object) so the FILL can be
transformed (we need to be able to disable tiling for images).
this will then allow for us to provide transformed image data but
within a
Carsten wrote:
the advice is i would like this and it would be good but its not
trivial to do right/well and right now i really don't have the time
to do it - thus it's one of those backburner when i get to it
things.
Ahhh... Well, if you're going to do it.. then I'll just
Simon wrote:
For the GL engine, you can probably modify the texture matrix to
transform the filling of an image. I'm not sure how well it would
work with borders though (but actually, what borders mean when
the fill is transformed?)
Two different sets of 'transforms' are
Jason wrote:
2. GL engine a second class citizen. I sometimes read on e-devel
about how this or that isn't working properly in the GL engine.
At some point configure was updated to no longer build it by
default. I'm afraid one day I'll do a svn update and discover
Jason wrote:
This is definitely a big deal for us (Freevo). We've been resorting
to ugly hacks to get this effect in text (i.e. using Imlib2 to render
the text to an evas image object and fiddling with the alpha channel
after), but other hacks are increasingly impractical for
[things about transforms and such]
Most of this, and clipping (and some other things), are coming
hopefully within this month or so. But there are things you should
be aware of.
Generally speaking, it's not too difficult to do any of these
things - especially if one
Enlightenment CVS committal
Author : raster
Project : e17
Module : apps/e
Log Message:
move custom file stuff to another file - e_fm.[ch] is becoming
a bit of a monster.
Why not kill the monster, or maybe just tame it somewhat.
Couldn't you use evfs for the back-end stuff?
That would seem like it could save a lot of work/code duplication
-- and would potentially give you the back-end support for the
various fs types that evfs already supports.. and also provide
back-end support for things like the trash can - something that
e17 will eventually want.
Here, the void *engine_data holds any engine specific
stuff, eg. for the xrender based engines this would be similar to
the current XRImage structure (minus certain things).
actually - this is a problem. you need to be able to have MULTIPLE
engine share the same cached image
Simon wrote:
Actually, what I really want is a GL engine that is not aware
of the rendering-target, i.e. an engine that can render
indifferently to the backbuffer, to the fronbuffer, to a texture,
to a pbuffer... and independently of the windowing system used.
Here would be the
Cedric's sdl engine email/patch has been hijacked into
a bitter battle over evas and opengl :)
Simon wrote:
It would indeed make the engine generic but then, if the engine
swaps the buffers by itself, the Evas couldn't be integrated in
an OpenGL application: here is how we
About your second point, The gl-engine can render to a texture or a
pbuffer, there is no problem with this, as long as it doesn't swap
the buffers. But as raster said, it is not possible if we want to
get good performances with OpenGL, rendering to a texture is slow
as hell (don't know muck
I wrote:
I don't know Simon.. want you want is certainly 'seductive'
in its own way - it does have a lot of good aspects -- but I wonder
if it's maybe just more gl-convenient than really necessary.
On the other hand While I think that engine specific
buffers, both as
Dan wrote:
1) Rewrite/update the user guide on get-e.org and move it in the
official site as user documentation. It will cover ONLY e17 itself
and the official modules (ibar, ibox, etc etc)
We can cover other applications as we see fit. There is no reason it
has to be just e17.
Gustavo wrote:
I'm developing python bindings for Evas, Ecore, Edje and like...
while still at the beginning, some issues are already showing
This may or may not be of any help, but perhaps you may want
to look into Tilman's (http://code-monkey.de) ruby bindings for eet,
evas,
I missed this one by Brian..
Write an app that sets
ecore_evas_alpha_set(ee, 1);
ecore_evas_borderless_set(ee, 1);
and run a compositor?
Then, if desired set them to stack 'always below', and either
alt-drag them around or use esmart_draggies?
That might be one way
Hannes wrote:
...
...
In short: there are a bunch of other modules that need to control
how and where they appear on the desk; modules which might have
multiple instance configurations to store.
I would say engage, devian, calendar and all this desklet-stuff
falls in this
I wrote:
Out of curiosity I looked up desklet and found references
to 'gdesklets' and 'SuperKaramba', which it seems are very popular
projects for gnome and kde respectively.
But there also came up something called 'adesklets', which
is a similar independent project
1 - 100 of 312 matches
Mail list logo
