I did test this patch since three month in my apps and in E, and I didn't
notice anything going wrong with it. If you experience strange bug with
matching please report them.
SVN revision: 35945
them from being put in the evas_render_update phase.
I did extensively test this patch since a few month and didn't notice any
bug with it in my apps, nor in E. But please report anything that goes wrong
for you after this version.
SVN revision: 35944
Edje is tricky, it's event processing is too weird and Cedric's
changes to make it work are not working as expected. Edje freezes
itself while processing signals, but in mouse down cb it forces
recalculate, which seems was previously ignored, but now they are not.
We should look at how to fix this and then re-apply this patch.
SVN revision: 35908
:)... this allows e etc. to adapt to massivelyt different dpi screens with
slickness that even svg can't get to... why? you scale just what NEEDS
scaling (text, button sizes, and other limiting elements). other bits like
borders, padding etc. can remain pixel-perfect and thus the look is amazing.
pixel-perfect drawing with scalable adapting.
SVN revision: 35895
Some people is using it for some time now without problems, so I'm
adding it to SVN to get some broader use. Remember to recompile ALL
libraries that depend on Evas as it will change the
EVAS_SMART_CLASS_VERSION and old classes will fail to load.
This will also change Edje so it will postpone _edje_recalc() to
render time, calculate() callback, however some methods will force
early recalculation.
SVN revision: 35860
Some methods do no change object internal state and can be marked as
read only. In parallel have infamous edje_object_part_object_get() to
return a read-only object, so it's even more clear that one should not
touch this object state (either a cast or a compiler warning if you do
that!)
SVN revision: 35485
The type "char" is not defined to have a sign or not, for performance
issue some platforms (ie: ARM) define it as unsigned. If we need to
rely on the sign, must say so.
SVN revision: 34924
having an almost parallel codepath for script_only objects - they dont get to
use the older edje api calls for part defined objects. they will have a new
set of calls specifically for them. it's partly done - very little available
now, but will expand. lots of fixme's.
SVN revision: 34699
* remove printfs that clutter output
* add efreet file type check - only parse regular files
* chekc mmap returns correctly for MAP_FAILED results
* edje has some stubs for adding script-only objecvts - but nothing useful
right now
SVN revision: 34689
Parts can choose to ignore Events with certain flags in event_flags. The default value is
to accept all events. The syntax for this is specifying in the part:
ignore_flags: ON_HOLD;
I've tried to update Edje_Edit bits also.
SVN revision: 34170
Edje tries to copy original style to font provided by text_class if
this have no style.
However code was supposing that text_class font always had more than
one occurrence, these separated with ',' and did not check if this is
not the case, so "e = strchr(',', tok);" was returning NULL and all
the math were using negative values.
The fix now does the proper checking, avoid one useless alloca() and
the respective copy, also doing the copies with memcpy() since sizes
are already known.
Refactory was done to make code simpler and also avoid having it
copied 3 times.
SVN revision: 33869
Check if values actually differ before interpolating them, this will
avoid useless math for (x1 - (x1 - x2) * p) when x1 and x2 are equal.
Also don't interpolate values that doesn't make sense to the part,
like color2 and color3 for non-text.
TODO: Refactor edje part description into more object-oriented
fashion, with a struct with just the common parts followed by an union
of structs for special objects, these would contain specific bits for
each part type. This would save us a bit of memory and then we can
more easily refactor code isolating common and specific parts, making
code smaller and easier to handle.
SVN revision: 33861
My last patch fixed the compile problem, but really, we should use the
same struct for things that look/work the same, like rectangle,
position, etc.
This new patch brings that change back and add some named structs
(also typedef'ed so it conforms to E naming schema).
This commit just changes the header and adds an example of
benefit. Later I'll provide a more intrusive patch that reorganize
structures to make even better use of this.
SVN revision: 33860
The "simple" block:
p3 = p1;
was doing an implicity memcpy() responsible for about 1% of processing
time when no animation happens.
Patch by Cedric BAIL.
SVN revision: 33858
Last 2 patches were swapped, I applied them in the wrong order and
missed the rejections, my bad.
I fixed it and also did some cleanup, looks better now.
SVN revision: 33855
Just allocate and build the match automate for callbacks and programs
only when required. On load for programs and when callbacks list has
been updated.
Patch by Cedric BAIL. (with minor fixes to use TABS where context was using)
SVN revision: 33804
Font names can contain spaces, either in the file name and the
fontconfig, so do the escape and keep words linked.
Now it's possible to have things like:
font=Vera\\ Sans:style=Bold
and it will work. (note double \\ is required)
SVN revision: 33526
Before it was using a linear search with initial step proportional to
difference bettwen desired and current height, but the way it was
implemented it was giving incorrect values, for example: a text in
an animation that enlarges height was getting size_{n} < size_{n-1},
where it should be always the oposite (the sequence was like: 31, 32,
33, 34, 31, 33, 34, 35, ...).
One way to avoid that was to recalculate "dif" based on new "th",
but it quickly drop to 1.
The current implementation now uses a binary search to find the first
size that matches the desired height and then a linear search to
search the largest font doing that (differents sizes may result in the
same height). This linear search is often an extra lookup and can be
avoided if we want just something that fits (instead of the largest).
SVN revision: 32146
Due my last change, the code was broken by edjes without a group
min/max, this happens because edje_object_size_max_get() returns
100000 for these objects, and this was being used as object maximum
size.
Current fix is a hack: just check for this value, now known as
EDJE_INF_MAX_*, but the real solution would be to return 0 (or -1) and
check for it in other parts of the code, but it's harder to get right.
SVN revision: 32123
I'm not sure this is the right thing to do, but since we're setting it
to 1 when "mouse_events: 0", it fix some problems.
Maye we shouldn't set this flag at all and let users have these
options set on clippers?
SVN revision: 32120
If you have a SWALLOW part taking the whole window and then swallow an
object with max set using edje_extern_object_max_size_set() it will
not take effect due the comparison of ep->swallow_params.max.w < -1
(desc->max.w is -1 in this case).
SVN revision: 32029
* add libtool versioning from the package version (from raster's
management of package version)
* replace AM_PROG_LIBTOOL(deprecated) by AC_PROG_LIBTOOL
* remove AM_ENABLE_SHARED as shared lib is built by default
* add AC_LIBTOOL_WIN32_DLL for libraries ported to Windows (tm)
* remove the libtool checks of c++ and fortran compilers
* remove PACKAGE_*_DIR from configure.in and define them in
Makefile.am as bindir and al. are expanded in them.
please report any problem that these changes can add
SVN revision: 31999
This avoid crashes with buggy edje files: if you forget to specify
type: RECT and don't provide any "images.image" in edje, it crashes.
SVN revision: 31689
Evas now support objects that do not grab mouse down event (NOGRAB) aside
with the default (AUTOGRAB). API is meant to be extensible.
SVN revision: 30950
These can be used to automatically swallow in another group from the same file.
Parts within child groups can be referred to by a ':' separated 'full path' of
part names. Any API functions that take a part name will now accept a full path
also.
Signals emitted by child objects will be repeated up to the parents with the
source changed to be the path relative to the receiving object. E.g in the
example below, a mouse moving over the lower light green rectangle would result
in the parent object recieving a "mouse,move" signal with source "bot:inner".
**** NEW RESTRICTION **** part names should no longer include a ':' character.
This is not yet enforced by edje_cc, but will cause the part to be inaccessible
from the API.
Example EDC:
collections {
group {
name: "parent";
parts {
part {
name: "top";
type: GROUP;
source: "child";
description {
state: "default" 0.0;
rel2.relative: 1 0.5;
}
}
part {
name: "bot";
type: GROUP;
source: "child";
description {
state: "default" 0.0;
rel1.relative: 0 0.5;
}
}
}
}
group {
name: "child";
parts {
part {
name: "base";
type: RECT;
description {
state: "default" 0.0;
color: 160 208 8 255;
}
}
part {
name: "inner";
type: RECT;
description {
state: "default" 0.0;
rel1.offset: 10 10;
rel2.offset: -11 -11;
color: 210 228 76 255;
}
}
}
}
}
SVN revision: 30087
it sould be
2. fixed edje handling of delete of objects so we don't lose clip info if we
move a swallowed object out
3. fix up norender stuff for evas a bit
4. pants.
5. coogee beach (sydney) in summer right now is beatiful - KICK ASS!
SVN revision: 28102
used (inside a part description) as follows:
Horizontal from left to right filling entire part:
gradient {
spectrum: "black_to_white";
rel1 {
relative: 0 0.5;
offset: 0 0;
}
rel2 {
relative: 1 0.5;
offset: -1 0;
}
}
Diagonal from top left to bottom right:
gradient {
spectrum: "black_to_white";
rel1 {
relative: 0 0;
offset: 0 0;
}
rel2 {
relative: 1 1;
offset: -1 -1;
}
}
If either rel1 or rel2 is present in the gradient block of a linear gradient, these will override any angle/origin/size specified in the fill block ('spread' is still honored).
SVN revision: 24975
* Fix edje font order (source, size, font) . This is needed so that evas
when parsing the style will only try to load the font once it sees the
font name. otherwise, if we load before we know where the source is and
fontconfig will takeover and load up all of its fallbacks.
* Remove inheritance. This is covered by evas. This means the text_class
will only modify style parameters which are already defined in the style.
SVN revision: 21533
* Classes are defined at the tag level
* Tags whithout classes inherit the parent class
* text class defined by putting text_class=<class name> in tag style
SVN revision: 21518
also, it seems as though default descriptions at least are shared between objects of the same group, so when this set the color_class to NULL, all other objects lost their colors.
SVN revision: 20098
this allows you to specify the default color for any parts using color_classes in a given file.
this color will be overridden by edje_color_class_set()
which will in turn be overridden by edje_object_color_class_set()
note. if you specify a color (color: ...) in a part description that also has a color_class, the cc will be multiplied against the color -- generally not what you want.
also, as a tip, the gimp's 'multiply' blend mode is almost exactly the same as evas/edje's coloring.
example:
...
part {
name: "colored";
type: RECT;
description {
state: "default" 0.0;
color_class: "bg_color";
/* note: no color: set here */
}
}
...
color_classes {
color_class {
name: "bg_color";
color: 229 239 255 255;
}
}
SVN revision: 19708
this allows you to specify the default color for any parts using color_classes in a given file.
this color will be overridden by edje_color_class_set()
which will in turn be overridden by edje_object_color_class_set()
note. if you specify a color (color: ...) in a part description that also has a color_class, the cc will be multiplied against the color -- generally not what you want.
also, as a tip, the gimp's 'multiply' blend mode is almost exactly the same as evas/edje's coloring.
example:
...
part {
name: "colored";
type: RECT;
description {
state: "default" 0.0;
color_class: "bg_color";
/* note: no color: set here */
}
}
...
color_classes {
color_class {
name: "bg_color";
color: 229 239 255 255;
}
}
SVN revision: 19707
Carsten Haitzler
Davide Andreoli
Gustavo Sverzut Barbieri
Cedric BAIL
Sebastian Dransfeld
doursse
Caio Marcelo de Oliveira Filho
Christopher Michael
rephorm
Peter Wehrfritz
Stafford Mitchell Horne
moom
tilman
ningerso
Viktor Kojouharov
metrics
sebastid
stffrdhrn
tsauerbeck
codewarrior
rbdpngn