(Not fully protocol compliant yet... I think we still need to check
and set atoms for individual actions, rather than just xdndActionList?)
Don't send additional position messages if target hasn't responded with
a status message.
Kevin Brosius <cobra@compuserve.com>
SVN revision: 5764
set as the basename of the file (ie "/tmp/blah/foo.png has the name of
"foo"). you can override the name if u want... or just not use it. should
really use hash table - patch for this from rusty russel :) i need to wokr
on this stuff before 1.0
SVN revision: 5652
this header file up. Macros first, enums, typedefs, then functions.
I've moved the typedefs to the struct definitions as this makes
the file a good deal shorter.
I've also tried to group the calls by topic, but the lack of a
consistent naming scheme makes this difficult.
SVN revision: 5601
e_x.c:1737: warning: `return' with no value, in function returning non-void
e_x.c:1781: warning: this function may return with or without a value
e_x.c: In function `ecore_dnd_selection_convert':
e_x.c:2081: warning: `return' with no value, in function returning non-void
e_x.c:2091: warning: this function may return with or without a value
e_x.c: In function `ecore_window_get_gravity':
e_x.c:2760: warning: `return' with no value, in function returning non-void
e_x.c:2763: warning: this function may return with or without a value
e_x.c: In function `ecore_window_get_border_width':
e_x.c:3181: warning: `return' with no value, in function returning non-void
e_x.c:3188: warning: this function may return with or without a value
e_x.c: In function `ecore_window_get_wm_size_hints':
e_x.c:3196: warning: `return' with no value, in function returning non-void
e_x.c:3200: warning: this function may return with or without a value
e_x.c: In function `ecore_window_is_visible':
e_x.c:3207: warning: `return' with no value, in function returning non-void
e_x.c:3217: warning: this function may return with or without a value
e_x.c: In function `ecore_window_is_normal':
e_x.c:3224: warning: `return' with no value, in function returning non-void
e_x.c:3234: warning: this function may return with or without a value
e_x.c: In function `ecore_window_is_manageable':
e_x.c:3241: warning: `return' with no value, in function returning non-void
e_x.c:3252: warning: this function may return with or without a value
e_x.c: In function `ecore_window_get_title':
e_x.c:3292: warning: `return' with no value, in function returning non-void
e_x.c:3319: warning: this function may return with or without a value
...
Fixed tens of cases where non-void functions returned nothing, plus
renamed "class" to "name_class" in Ecore.h. Thanks for the hint,
Olivier.
SVN revision: 5599
object inthe evas are in layers above the new one.. fix fix oops.. that was
a silly bug... :)
and well.. while i was at it.. some actual code in the render extension
support in the render engine in evas.. it onyl does image objects right
now.. and it doesnt do it very optimally.. consider that engine a work in
progres.. i'm finding what does and doesnt work well in the render extension
and noticing some holes in it... this one wont be ready any time soon
though... and the gl engine is still about 10 times faster on the same
hardware... and in theory both are hardware accelerated...
anyway only time will tell. the render extension doesnt do image
transforms.. so this wont help speed it up at all that much :(
SVN revision: 5267
1. they are rendered completely unclipped by clip obejcts or edges of the
canvas for more than 16 iterations at the same size with no border scaling
2. it will throw thme out if things chnage
3. it will share image objects only of original size :)
SVN revision: 5139
the actual configure checks for imlib2 as the script shoudl contain all the
stuff needed - all it needs to do is chekc the imlib2-config script is alive
and around. thats all.
SVN revision: 4978
texture generation is 850% faster now that.. I err.. bypass libGLU - GLU is
err.. SLOOOOOOW as balls when it comes to mipmap generation
SVN revision: 4677
kept resident as long as the obejct has been rendered at leats once AND it
is still within the viewport of the output of the evas and it is still
visible. if it does not meet these conditiosn it gets put into "Cache" and
only then does cache become an issue. the chancges were nice and small to do
this :)
SVN revision: 4634