This should probably become the new standard for coords as it doesn't
clash with the damn y1 posix function.
Thasks to Gustavo for the naming.
SVN revision: 67325
Long time ago, in
http://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg32795.html
mail thread and IRC,
I talked with about problem of asynchronous event API such as
ecore_imf_context_commit_event_add,
ecore_imf_context_preedit_changed_event_add, so on.
In short, The problem is that key event and text_set APIs are processed
immediately, but commit event and preedit changed event is processed
asynchronously because those APIs add each event to ecore event queue.
To fix these problems, I've decided to create synchronous event APIs such
as ecore_imf_context_event_callback_add, del and call.
For considering compatibility, sync and async event callback functions are
used in xim and scim immodule.
SVN revision: 67290
be 1.1 (or 1.5) for the last release. too late. THIS is why i'm sick
and tired of all the bloody separate libs that have to be versiioned
and build and released separately. :( too many places to go fix up per
release.
SVN revision: 67284
Global shadow warnings are annoying and thus will be ignored at the moment,
There are other issues as well though, for example, not using cpp_token_file.
I don't know if that's intended or not, so I won't just suppress the warning.
SVN revision: 67242
allows us to multiple a minimim size explicitly for min size calc so
we can do things like have content slide open/closed properly.
SVN revision: 67197
This is so that future scripts will still work with old libraries,
and lets us add the "host can provide Lua API" feature soon.
Also some more comments.
SVN revision: 66961
NOTE: it's just a partial revert of previous patch by
raster. Without that, some text were flickering going
on and off for sometime. I didn't take the time to
understand why, but by forcing the recalc it permanently
solve the issue.
SVN revision: 66903
NOTE: I am still wondering what is the cost difference between
forcing a request to eet_open and calling stat. If someone has some
time to benchmark, feel free to do so and report on e-devel ml.
SVN revision: 66902
differently. When inputting Korean text, preediting text will be shown
as selected. When inputting Japaneses text, preediting text will be
shown with underline. (Sometimes shown as selected for changing whole
preediting text to another text)
SVN revision: 66580
r66257 <- another small fix on the real problem
r66250 <- a small fix on the real problem
r66242 <- the real problem
jaewhan - your commit yesterday (r66242) has made edje_cc very
unstable and it will randomly segv (sometimes yes, sometimes no). as
such it's at the point i can't even compile e and elm without it
segving somewhere during build, so this gets backed out. review your
change carefully and look for issues.
SVN revision: 66265
Lately, raster removed the code about the prohibition of type-change in
group inherit.
But about the "part" of different type, the data structure of the their
"description" is different.
So if the type is changed, it have to be reallocated. Current, it is not.
At first, we have to remove the lookups. If we don't, when lookup module
executes, the memory
may be broken. So I removed all lookups for reallocated description before
it is reallocated.
And I changed all description of the "part" is reallocated when the type is
changed.
The attribute of the "part" is remained. Just it reallocated the part of
**_Spec_**.
SVN revision: 66242
NOTE: This was necessary for solving issue with the new CURRENT feature. I
don't like this massive change, but there is no way around. This patch is
only the first step, I will wait the full night before completly fixing
the issue with CURRENT.
WARNING: If this patch doesn't break svn, you must feel lucky and go play
money games. In all other case, please report any issue to the developper
mailing-list.
SVN revision: 65619
and.... u get the idea. this made an n^m list of messages... where n
was 3 of messages sent and m was # of child parts (42 of them)... this
caused a silly 3 of timers to be allocated... don't ask how many. in a
simple snapshot i saw 101mb of timers allocated... and i was just
starting... anyway - this makes the propagatiopn not propagate down
and then back up again... and it only needs 1 timer allocated to
handle a re-schedule of processing messages. not N. "leak" that was
just a massive memory spike) is now fixed.
SVN revision: 65571