> >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 po
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 & dr
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
> > 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.
>
> http://beta.
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 actu
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
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
>
> > 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
> 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
> > 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
> > 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 no
> 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 you want is an:
>
> evas_object_image_rescale(Evas_Object *obj, int w, int h);
> which forcibly rescales ANY image to a particular size - be it
> loaded from a file or generated as ARGB data. this gives you the
This has been something I've suggested to you before, many
times - it
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
> i
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 wa
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
> >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
> 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' t
> > 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 e
Andres wrote:
> I spent hundreds of hours learning and writing about the EFL and
> all this time will be wasted if the flagship product of the EFL,
> the dr17 window manager, is not released in a reasonable time frame.
That's a great contribution and personal effort on your part,
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. Every
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 fil
> > 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_Ev
> > 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-
> > 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
> 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 don
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
> funct
> - 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, a
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 oth
> 1. An engine that can render to such a native surface buffer (rather
>than using the software argb buffer engine).
> 2. Implement evas image 'native surfaces' for the kinds of buffer
> surfaces you use in (1) above.
I should add that (2) isn't really needed for most uses, it'd
jus
> > There are a couple of other smart class functions that would
> > also be useful with smart objects, in particular min/max_size_get
> > functions, and add similar functions to the evas api so that one
> > can query an evas object's min/max size.
>
> I already though about that, and perhap
> 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' whe
> Furthermore in the function __imlib_hsv_to_rgb an improved behavior
> could be achieved if the last case statement in the switch would be
> replaced with a default.
Give it a shot and see if it fixes the issues you experienced.
You might also want to look at evas' hsv-to-rgb function:
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
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 togeth
> Recording them into wiki.enlightenment.org would probably be the
> best bet. A much more stable and easy to use record then the
> mailing list.
Eventually, yes. But initially, the list is a much, much
better forum for feedback and tossing around some general ideas..
Let's not dampen pub
> 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
> > Recording them into wiki.enlightenment.org would probably be the
> > best bet. A much more stable and easy to use record then the
> > mailing list.
>
> Eventually, yes. But initially, the list is a much, much
> better forum for feedback and tossing around some general ideas..
> Let's no
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 ad
> Recording them into wiki.enlightenment.org would probably be the
> best bet. A much more stable and easy to use record then the
> mailing list.
BTW, wouldn't it be a good idea to have a link to the wiki
from the main enlightenment.org site? I had no idea how to find that
and had to star
Ok, here are just a few 'ideas' that I think would be nice,
not necessarily anything to do with SoC, just a few things I think
e could benefit from (merely from my own viewpoint).
1. Further work on an immediate-mode gfx lib like enesim, and also
on a generic canvas framework as in jor
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 th
> I replaced both functions as you suggested. No it looks a little
> better but not much.
> From my perspective the problem is that imlib2 stores color ranges
> internally in rgb.
In part.. As I mentioned, the use of the wrong scale was only
part of the problem. The other part is that it'
> 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
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 ask
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
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 co
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
>
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
> > > e
Gustavo wrote:
> I agree with use case of fixed filters, actually the proposed
> filters cover more than what I expect. What I disagree is
> _having_ to implement a span of combinations in order to optimize
> it for all engines, it will not worth the pain. Ok if one wants
> to do that, bu
Carsten wrote:
> ... what would be the right way would be to allow new extended
> objects (smart objects) to set rendering calls - the same way
> evas internal objects do, and then do their own rendering.
> breaking this out to a nice public api would be really nice and
> allow for objec
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!
http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nkM
> > Also, how can one 'set' an object's min/max size? Wouldn't
> > these be intrinsic to the object?
>
> for other objects it may or may not be, but thats why set()
> calls exist - to set it.
Makes no sense to me, nor for the 'request' one either
if that means something like
> > 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
> > I want to here what you like. I only want to hear it _once_.
> > I _don't_ want to hear you bitch about what someone else likes.
>
> I want a pony.
>
I want a bicycle.
-
Using Tomcat but need to do more? Need to s
Just a note on the evas move-to-premul stuff. Some things
are taking me a bit more time than I had thought, so it looks like
I may not finish with it til the weekend.. we'll see.
Let me give a quick recap of the api funcs that this change
will involve.
There are four util
> > Since we're 'breaking' stuff and going over things -- I went
> > ahead and *removed* the current "evas_object_gradient_data_unset"
> > api function.
> >
> > Why..? Well, its functionality can be obtained by setting
> > new data/adata, or by the colors-clear api func (which will clear
> >
Jason writes:
> > Much ado about gradients, but hopefully all this will make
> > it easier to work with grads in current edje and otherwise.
>
> Forgive me for chiming in when I haven't read the full thread nor
> grokked the context, but does any of your work allow being able
> to set gra
> > Much ado about gradients, but hopefully all this will make
> > it easier to work with grads in current edje and otherwise.
> >
> > Comments...?
>
> sounds good - one thing i did notice - gradient fills are a lot
> slower than images... :) i noticed when cross-fading wallpapers
> @ 1600
> > Nevertheless, yes grads can definately benefit from some
> > optimizations :)
> there we go - that's all i want to mention :) they aren't
> "close to optimal" YET :)
Well, patches are welcome you know :)
Do not frett, o speedfreak.. I've just taken care of it.
>Jason writes:
> > > Much ado about gradients, but hopefully all this will make
> > > it easier to work with grads in current edje and otherwise.
> >
> > Forgive me for chiming in when I haven't read the full thread
> > nor grokked the context, but does any of your work allow being
> > abl
> it can't. it's a window. just like tray icons. windows cant be
> part of a canvas.
I think that given the current design of the systray spec,
what we have here is just that, currently, implementing this may
give ugly stuff for many systray-apps.. But I don't think it means
that the conc
Michael writes:
> Welcome to the Bazaar. If you would prefer to work in a Cathedral,
> please note that you will not find one here.
For either method to work though.. cooperation and a certain
set of guidelines are needed. That's why you have "rights" to CVS
commit access.. For
Well long overdue, and could use much more testing.. but
I may as well send this for others to check and test if they wish :)
We've mentioned what this 'evas premul' move means before,
so I won't repeat it here, but anyone with any questions please feel
free to ask.
There
Vincent writes:
> I have a question. The software engines are working in non-premul,
> whereas the xrender ones do. Is there any improvement in the speed,
> wrt the xrender engines ? (I've not installed your patch yet)
Did it go thru? I seem to not have had it forwarded...
> I've attached the evas-premul diff (rather largish but...
Attachement didn't seem to go thru. Ummm... Let's try again
and see what happens (it's a 124Kb "evas_premul.tgz" file).
jose.
-
Take Surveys. Earn C
Attachements still a no-op. Ummm. will try again another time
and see if I have better luck then.
jose.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll
> Attachements still a no-op. Ummm. will try again another time
> and see if I have better luck then.
>
> jose.
It seems that sf doesn't like non-text attachments, and this
patch is simply too large uncompressed (like 1.4Mb).
Just to let anyone who might be wondering
> > Just to let anyone who might be wondering what happenend --
> > I've sent a copy to raster and he's already on it... :)
>
> and the bitch has hit cvs :)
Oh boy.
Man that's remarkable you were able to get so much stuff
fixed up to work with it so quickly.. :)
> Author : raster
> Project : e17
> Module : libs/evas
>
> Dir : e17/libs/evas/src/modules/loaders/eet
>
> Modified Files: evas_image_load_eet.c
>
> Log Message:
>
> fix eet load of premul images - need to check they are not "bad" :)
>
Ummm... How about adding a 'premul' flag
> > Ummm... How about adding a 'premul' flag to eet images, which
> > would be set/read accordingly...
>
> i could... but i would need to break eet api... and i'm just as
> happy to break format - premul encoding can be more efficient
> compression-wise by nulling out transparent pixels. :)
> > also, line 1329 should now read:
> >
> > evas_object_gradient_color_stop_add(ep->object,
> > sc->r, sc->g, sc->b, 255, sc->d);
> > evas_object_gradient_alpha_stop_add(ep->object, sc->a, sc->d);
>
> hmm - color stop can't add the alpha directly as-is?
Yes,
Brian writes:
> I'll look at the bg dialog within the next couple of days
> (pretty busy with work atm. unfortunately). And I definitely
> plan on cleaning up the edje grads a bit. Just gotta find some
> time again. :)
Sounds good :) Edje grads should be easier and more
flexib
> > Did this happen before the move to premul?
>
> no - i think it worked.
>
You don't sound too certain.. ;)
It's possible but I'm having doubts that it ever did.
Here's why:
1. It works fine for images.
2. Grad recoloring works just fine in evas.
3. I actually modified ed
I wrote:
> I think this is some subtle grad id problem, or some such, in
> the way edje grads are defined.. or some other part of the code that
> may deal with 'transitions'.
Ummm I wonder if it may be that there's absolutely no
support for edje grads in edje_embryo. Th
I wrote:
> I think this is some subtle grad id problem, or some such, in
> the way edje grads are defined.. or some other part of the code that
> may deal with 'transitions'.
>
and also,
> Since Brian is busy with things, it looks like I may have to
> see if I can so
As I mentioned in an earlier email (which for some reason
I've yet to see show up), the odd behaviour of grads w.r.t. changing
bgs in e17, turned out to be entirely due to an error in the evas
grad code, NOT in edje.. Brian's edje-grads work fine! :)
Attached is an evas patch to take care
I hadn't run e17 for a few months, and just recently
updated it and did so.. Many new good things here - imagine
how much could be done if the work done over the last couple
of months could continue! :)
I have some personal criticisms and requests though,
just based on first impr
> > > I have some personal criticisms and requests though,
> > > just based on first impressions of a few minutes of use... :)
> >
> > You should use it for more than a few minutes before complaining.
>
> aye.
>
Naye. First impressions are of the utmost importance,
that's why I deli
Nathan writes:
> I received a bug report from Lutin on #edevelop today that
> indicated that evas would not build on PPC linux with the FB
> engine enabled because PAGE_MASK is not defined.
>
I thought that Jorge (aka. turran) was going to do some
work on the evas fb engine, and
David writes:
> > Sardines are quite good with beer or wine.
>
> Don't like beer or wine either.
Hopefully, after seeing how much was done in such a short
time, someone else will step up to the plate.. and offer something
better ;)
jose.
--
> > I can use it for hours/days/... and get a different idea,
> > and I can look thru the src code and get yet another viewpoint..
> > But neither will equal that 'first-impression' viewpoint.
>
> the fallacy is that you have first impressions of something
> totally incomplete.
>
> "this house i
> > I thought that Jorge (aka. turran) was going to do some
> > work on the evas fb engine, and also ecore_fb, but don't know if
> > he's had a chance to get to that or not.
>
> yeah i do have plans for it, but with the changes on the way evas
> engines will behave, i prefer to not touch it
> Ok, so what are the set of basic engine funcs, and obj
> funcs, that will need to be provided?
>
> To be continued :)
>
Well, let's take a look at 'objs' first. Internally, the
basic evas_obj structure keeps some things that we're interested
in here:
Its 'type'
Wagner writes:
>
>
>
> so, now are my questions :
>
> would it be a good idea to add support for arabic text
> (and hebrew, and complex languages) ?
>
> which functions would need to be modified ?
> (are for example some functions returning string lenghts ?)
>
> how is text i
> To be continued :)
>
Well, the prior emails pretty much outline all that I have in
mind here as far as objs/engines re-structuring: Modular units which
when called upon to add an evas obj to an evas canvas would either
use a default 'generic' set of funcs, or load an implement
> > Hi all.
> >
> > I can't be sure about this, but I *think* the quality of icons
> > based on svg images has dropped recently. If I make an application
> > icon based on a png file, when I put it in the bar and point at it
> > ( with the darkness theme, that zooms icons when you point at the
>
> > Hi all.
> >
> > I can't be sure about this, but I *think* the quality of icons
> > based on svg images has dropped recently. If I make an application
>
> I can't really imagine why they would look much different, vs.
> scaling pngs, now from before. As raster mentions, it uses the same
> sca
I'll get back your other points a bit later Jorge :)
But let me just quickly reply to the following part:
> call an engine function (this is why it is called "object engine")
> which will send a protocol command. The problem with this is that
> now almost every "canvas api" function (obje
Ok, now that I have a bit more time to reply... :)
> i have a few doubts about objects and engines and how to implement
> what we need. I think the idea of making engines be just blitters
> is a good thing, also convert the objects to module units. But
> (as you noted) we have a problem w
Chad writes:
> I'm not sure if this is the same problem, but here is a screenshot
> I just took that may be realted:
> http://www.lunar-linux.org/~v3rt1g0/fuzzy.png
>
> On the left is iBar, with the orange BMPx icon. Presumably that
> same icon is also what you see in iBox on the right.
Daniel writes:
> Not really. Have a look at this:
> http://entropy.homelinux.org/blurry.png
> I'm *almost* certain that last time I created an icon for
> firefox based on the same svg, it scaled up perfectly.
That actually looks about right.. it looks like what you'd
get if you
> > Chad writes:
> >
> > > I'm not sure if this is the same problem, but here is a
> > > screenshot I just took that may be realted:
> > > http://www.lunar-linux.org/~v3rt1g0/fuzzy.png
> > >
> > > ...
> > > ...
> >
> > That's pretty bizarre indeed. Anyone else experienced
> > a simil
Ok, I took a bit of time to download and look thru Jorge's
"evas_core" work...
It's interesting that what he's done here is pretty much
what we've been going over, though it may not have seemed that way
to him :)
Jorge:
It doesn't matter what an 'engine' does with
> > > Likely evas will have general obj clipping not too far away,
> > > but 'buffer evases' are also interesting and useful (hence the
> > > ecore sub-canvases).
> >
> > I think it would be indeed really useful to have such objects:
> > I may be wrong but I think this kind of objects is the wa
Carsten writes:
> On Fri, 6 Oct 2006 13:31:19 +0200 "Jorge Luis Zapata Muga"
> <[EMAIL PROTECTED]> babbled:
> ...
> ...
>
> > btw a little offtopic, but now that the premul stuff is in,
> > isnt a good time to continue thinking/start coding the
I'm about to move out of evas-gradient-land for a while
and thought I'd mention some the last bits on them here, in case
anyone has any comments or suggestions.
I've recently added support for setting a (file,key) on a
grad obj, so that one can load spectra via evas' image loaders
1 - 100 of 357 matches
Mail list logo
