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
Carsten Haitzler
David Walter Seikel
Iván Briano
WooHyun Jung
Sebastian Dransfeld
Gustavo Lima Chaves
Cedric BAIL
Tom Hacohen
Jaehwan Kim
Mike Blumenkrantz