Twas brillig at 11:41:50 18.03.2010 UTC-07 when inchost...@gmail.com did gyre
and gimble:
IC> Well, No easy way to say it, so here's the email "Thank you
IC> for submitting "Enlightenment (E-17)" organization application to
IC> Google Summer of Code 2010. Unfortunately, we were unable to
Twas brillig at 16:02:08 05.03.2010 UTC-03 when bdi...@profusion.mobi did gyre
and gimble:
BD> Hey Mikhail, any news about your patch?
Still working on it. Textblock rendering is quite complex, I don't want
to broke anything by misunderstanding some internals.
--
http://fossarchy.blogspot.
Hi.
Recently had a look at cursors API and implementation in Textblock and
was amazed by it baroqueness: there are prepend/append functions, lots
of uncertainity of whether to include interval ends into the range or
not etc.
Just for the reference for e-devel@: cursors in Textblock point _to_
cha
This patch series is a set of small refactorings in evas_textblock. Should not
change
behaviour at all, just code de-duplication and adding comments.
--
Download Intel® Parallel Studio Eval
Try the new software tools for
Some copy-pasted code removed as a result.
---
trunk/evas/src/lib/canvas/evas_object_textblock.c | 62 -
1 files changed, 11 insertions(+), 51 deletions(-)
diff --git a/trunk/evas/src/lib/canvas/evas_object_textblock.c
b/trunk/evas/src/lib/canvas/evas_object_textblock.c
ind
They are used in single function, so don't keep them in structure.
As a side-effect rework _layout_line_advance for better readability.
---
trunk/evas/src/lib/canvas/evas_object_textblock.c | 93 -
1 files changed, 55 insertions(+), 38 deletions(-)
diff --git a/trunk/evas/sr
---
trunk/evas/src/lib/canvas/evas_object_textblock.c | 114 +---
1 files changed, 51 insertions(+), 63 deletions(-)
diff --git a/trunk/evas/src/lib/canvas/evas_object_textblock.c
b/trunk/evas/src/lib/canvas/evas_object_textblock.c
index ba7e664..826239a 100644
--- a/trunk/evas/
Twas brillig at 03:23:09 01.03.2010 UTC+06 when dotted...@dottedmag.net did
gyre and gimble:
MG> Here's the proposed patch
Please ignore it, it is broken. I am working on better patch which will
fix Textblock layouting (e.g. no artificial space before first line) and
allow for reduced line spa
Here's the proposed patch for Evas which removes extra checks and makes
it possible to reduce line spacing in Textblock (previously it was only
possible to make it bigger than default, and default gave me 34px with
14px-tall DejaVu Sans Condensed and cyrillic letters).
---
trunk/evas/src/lib/can
Twas brillig at 16:21:09 28.02.2010 UTC+01 when albin.tonne...@gmail.com did
gyre and gimble:
AT> I wouldn't consider using g_strdup_printf vs. asprintf an
AT> abuse. asprint is a GNU-specific extension, and is not guaranteed
AT> to be available. g_strdup_printf, OTOH, is part on the glib API
Twas brillig at 23:43:49 27.02.2010 UTC+00 when r...@1407.org did gyre and
gimble:
>>> Log:
>>> Replace g_strdup_printf with asprintf
>>
>> why do you replace all those g_* functions ?
RMSS> Reduce usage of glib to use more EFLs (as advised).
Makes code harder to read. FWIW.
--
http
Twas brillig at 11:38:15 18.11.2009 UTC+11 when ras...@rasterman.com did gyre
and gimble:
CHR> We
Please define "we".
--
http://fossarchy.blogspot.com/
pgpi4tKquYu4K.pgp
Description: PGP signature
--
Let Crystal
Twas brillig at 22:52:17 03.09.2009 UTC+02 when albin.tonne...@gmail.com did
gyre and gimble:
AT> In fact, most of what's in Libs currently shouldn't move to
AT> Libs.private, because they actually are justified.
Agreed. Had a look through EFL .pc files, their Libs are already ok
(actually th
Twas brillig at 22:30:44 03.09.2009 UTC+02 when vto...@univ-evry.fr did gyre
and gimble:
VT> Looks good to me. I've looked at others .og files (in fontconfig
VT> for example), and I have seen a Libs.private. SHould it be used ?
Yes, of course!
The rule of thumb is "when something is not need
ly) which adds check for pkg-version
and emits either Requires or Requires.private in generated .pc files.
--
http://fossarchy.blogspot.com/
pgpEHNBSofK1U.pgp
Description: PGP signature
>From 53f0b32bd7d8223f2be1650c9f2f2bef02c40ae5 Mon Sep 17 00:00:00 2001
From: Mikhail Gusarov
Date: Thu, 3
Twas brillig at 14:15:17 27.08.2009 UTC-03 when barbi...@profusion.mobi did
gyre and gimble:
GSB> having a daemon (dbus?) to do these things on behalf of
GSB> applications and notify properties changes would be awesome.
Is it really necessary? Watching the configuration file should be more
th
Twas brillig at 06:55:12 24.08.2009 UTC-04 when cpmicha...@comcast.net did gyre
and gimble:
CM> regardless of platform the returns are as expected.
NULL is declared as 0 in C standard. Consistency wins, I agree, but
portability is not hurt by using 0 instead of NULL.
--
http://fossarchy.bl
Twas brillig at 06:28:41 24.08.2009 UTC-04 when cpmicha...@comcast.net did gyre
and gimble:
CM> if (obj->delete_me) return 0;
CM> Shouldn't that be:
CM> if (obj->delete_me) return NULL;
./linux/stddef.h:#define NULL 0
--
http://fossarchy.blogspot.com/
pgpxxDGlAnKXA.pgp
Descrip
Twas brillig at 00:17:36 18.08.2009 UTC+10 when ras...@rasterman.com did gyre
and gimble:
CHR> but with only 16 real shades (gain you'll have to make assumptions
CHR> about this - or at least have a converter per display type - eg 64
CHR> colors (6bit) but only 16 levels (4bit) significant)m
CHR> 4096 colors? well there's the rgb16-444 - this is specifically for
CHR> displays using rgb565 as the rgb format but with only 4 bits per
CHR> rgb (thus dithering appropriately). but for dozens of
CHR> fps.. really? will updates look good?
Dunno, I did not test such screens yet. Though it
Twas brillig at 09:46:47 17.08.2009 UTC-03 when barbi...@profusion.mobi did
gyre and gimble:
GSB> Fine ebooks won't go with movies and animations,
They will. New technology for bi-stable screens, which allows several
dozens of fps and 4096 colors, is expected to be available for
production nex
Twas brillig at 21:56:21 17.08.2009 UTC+10 when ras...@rasterman.com did gyre
and gimble:
CHR> yes and no. at least the docs indicate it's a ramping transition
CHR> in values - we can shortcut and avoid a palette lookup to improve
CHR> speed. there's correct and then there's fast :) being fas
Twas brillig at 21:48:09 17.08.2009 UTC+10 when ras...@rasterman.com did gyre
and gimble:
CHR> wait - so its actually being psychotic with a palette like:
CHR> 0xff
CHR> 0x00
Right now driver exposes linear values as you'd expect (though I've seen
controllers which wanted pixel value
Twas brillig at 21:29:53 17.08.2009 UTC+10 when ras...@rasterman.com did gyre
and gimble:
That's it.
CHR> The values are typically in a linear or near-linear increasing
CHR> ramps. linear. increasing. typically. :)
/me patches the kernel driver: 0x0 -> #ff, 0x1 -> #00, 0x2 ->
#a
Twas brillig at 20:23:17 17.08.2009 UTC+10 when ras...@rasterman.com did gyre
and gimble:
CHR> hmm - no that's grayscale. grayscale is a gray only verison of
CHR> pseudocolor. staticgray == linear allocation of gray values (ie
CHR> what i described). at least so it says in the x protocol ref
Twas brillig at 19:31:21 17.08.2009 UTC+10 when ras...@rasterman.com did gyre
and gimble:
>> StaticGray
CHR> then that's defined i think as 0 -> N where N is the highest value
CHR> supported by the bits, and N being white, 0 being black. ?
Yes.
CHR> so no need for colormap games or palett
Twas brillig at 12:15:55 17.08.2009 UTC+10 when ras...@rasterman.com did gyre
and gimble:
CHR> you can query palettes in x - yes. XGetRGBColormaps() to read
CHR> colormaps. but i don't quite know how your x is set up? is it set
CHR> up that its default visual is a greyscale one? or indexed co
Twas brillig at 11:42:20 17.08.2009 UTC+10 when ras...@rasterman.com did gyre
and gimble:
CH(R> On Sun, 16 Aug 2009 20:25:10 +0700 Mikhail Gusarov
CH(R> said:
>> This is needed for E-Ink devices outta there. Names of new files,
>> configure.ac variables and macros are
Twas brillig at 11:23:15 17.08.2009 UTC+10 when ras...@rasterman.com did gyre
and gimble:
CHR> greayscale64? i thought they were 16 levels of grey (4bit)? well
CHR> the ones i saw? or is the 64 mapped to 16 with dithering?
Actually 4-16, depending on the controller. 64 is just due to the some
Twas brillig at 11:30:24 17.08.2009 UTC+10 when ras...@rasterman.com did gyre
and gimble:
CHR> On Mon, 17 Aug 2009 04:44:51 +0700 Mikhail Gusarov
CHR> said:
>> Is it ok to pass NULL parameters to ecore_evas_title_set /
>> ecore_evas_name_class_set? If yes, what's t
Twas brillig at 20:14:44 16.08.2009 UTC+07 when dotted...@dottedmag.net did
gyre and gimble:
MG> XCB used to provide iterators for requests returning
MG> list of values. Recent versions dropped it
And from the recent discussion in x...@lists.fd.o it became apparent that
it was a bug, so it is
Hello.
Is it ok to pass NULL parameters to ecore_evas_title_set /
ecore_evas_name_class_set? If yes, what's the expected reaction of
backend? Should it treat NULL parameters as empty strings or somehow
else?
--
http://fossarchy.blogspot.com/
pgpLZ1wRZzgIp.pgp
Description: PGP signature
-
Ecore_List -> Eina_List transition broke _ecore_xcb_cookie_cache:
due to leftover condition no cookies were added to cache at all,
making havoc and despair.
This patch removes offending check.
Signed-off-by: Mikhail Gusarov
---
src/lib/ecore_x/xcb/ecore_xcb_reply.c |3 ---
1 files chan
There is xcb_connection_has_error to check connection errors,
and return value of xcb_connect is always non-NULL.
Signed-off-by: Mikhail Gusarov
---
src/lib/ecore_x/xcb/ecore_xcb.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/lib/ecore_x/xcb/ecore_xcb.c b/src
Another set of ecore XCB patches, which I forgot to send last time.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focu
Twas brillig at 19:39:07 16.08.2009 UTC+02 when vto...@univ-evry.fr did gyre
and gimble:
VT> PS: so no problem with evas on a Xlib-less OS ?
Not enough info yet :) I've just rebased packages to svn-03 snapshot
From some ancient state.
--
http://fossarchy.blogspot.com/
pgpDmuZflsgms.pgp
D
Twas brillig at 16:37:14 16.08.2009 UTC+02 when albin.tonne...@gmail.com did
gyre and gimble:
>> Those symbols appeared earlier than in 1.2.2, but
>> debian/libeet1.symbols was not updated, so there is no point to look
>> at the actual minimal versions of symbols.
AT> Actually, it did get u
Those symbols appeared earlier than in 1.2.2, but debian/libeet1.symbols
was not updated, so there is no point to look at the actual minimal
versions of symbols.
Signed-off-by: Mikhail Gusarov
---
debian/libeet1.symbols | 42 ++
1 files changed, 42
This is needed for E-Ink devices outta there. Names of new files,
configure.ac variables and macros are awful, suggestions are welcome.
Signed-off-by: Mikhail Gusarov
---
configure.ac | 22
src/lib/engines/common/Makefile.am
xcb-utils break compatibility sometimes. xcb-icccm API
was disruptively changed in 0.3, while xcb-icccm 0.2 is still
common. Adjust code to use 0.3 versions of constants and
files while providing compatibility layer for 0.2
(to be removed ASAP).
Signed-off-by: Mikhail Gusarov
---
configure.ac
XCB used to provide iterators for requests returning
list of values. Recent versions dropped it and return
arrays instead. Adapt code to use arrays unconditionally
(arrays were present in earlier libxcb versions).
Signed-off-by: Mikhail Gusarov
---
src/lib/ecore_x/xcb/ecore_xcb.c| 20
Signed-off-by: Mikhail Gusarov
---
src/lib/ecore_x/xcb/ecore_xcb_region.c | 20 ++--
1 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/src/lib/ecore_x/xcb/ecore_xcb_region.c
b/src/lib/ecore_x/xcb/ecore_xcb_region.c
index ec2847c..5642332 100644
--- a/src/lib
This is a set of patches required to compile/run ecore on
Xlib-less X11 system with relatively recent libxcb/xcb-utils.
Fortunately the rest of stack does not need patching.
--
Let Crystal Reports handle the reporting -
Twas brillig at 11:40:17 11.07.2009 UTC-03 when barbi...@profusion.mobi did
gyre and gimble:
GSB> Efreet is a core technology for E17, but we need a maintainer for
GSB> it. Mekius is busy, as we all are, so if you have some spare time
GSB> to help with it, please say so :-)
Oh , noes! I onl
Twas brillig at 08:23:31 10.07.2009 UTC+02 when vto...@univ-evry.fr did
gyre and gimble:
Compile-tested evas & ecore on Xlib-less system.
evas compiles with a small patch attached below in the following
configuration: --disable-software-x11 --disable-software-16-x11
--enable-software-xcb --disab
evas_common_font_utf8_get_prev currently works correctly only on an
ASCII symbols. For non-ASCII it just returns random garbage somehow
constructed from a string.
Attached patch makes it work according to the comment at the start.
--
http://fossarchy.blogspot.com/
pgpBbWgra1FbF.pgp
Descript
Twas brillig at 00:04:48 02.07.2009 UTC-05 when mek...@mekius.net did gyre and
gimble:
NH> Efreet does not follow any of this new specification to my
NH> knowledge so updating it would probably help solve the problem you
NH> describe.
Hmm, updating what? Efreet, specification or mime-type de
Twas brillig at 07:10:55 29.06.2009 UTC+07 when dotted...@dottedmag.net did
gyre and gimble:
MG> Fix:
I've found a problem with this fix. Here's the correct one:
pgpfq9330r3I1.pgp
Description: PGP signature
Index: src/lib/efreet_mime.c
===
Hello,
I've stumbled upon the problem with lower-priority mime-types matching
in Efreet. Let's see the definition of application/x-palm-database and
application/x-aportisdoc:
Palm OS database
AportisDoc document
According to definition, file with .pd
Hello,
Efreet_Mime did not match last set of magics for given mime-type due to
missing check after the loop. This bug was partially masked by the
problem fixed in my previous patch.
Fix:
pgprZD6FXbEVv.pgp
Description: PGP signature
Index: src/lib/efreet_mime.c
=
Hello,
I've fixed a bug in parsing magic file in Efreet_Mime: if some magic
rule has a subrule with non-zero depth, then the 0 depth is used instead
for subrule. This led to nonsense like all .xml documents matched as
application/docbook+xml.
Here's the simple patch:
pgpNsgbNupdux.pgp
Descript
---
src/engines/xcb/ewl_engine_xcb.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/src/engines/xcb/ewl_engine_xcb.c b/src/engines/xcb/ewl_engine_xcb.c
index 4a8c32e..1452f6e 100644
--- a/src/engines/xcb/ewl_engine_xcb.c
+++ b/src/engines/xcb/ewl_engine_xcb.c
@@ -1
---
configure.ac |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index b1156ad..558af0f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -72,8 +72,6 @@ requirements="evas ecore edje"
PKG_CHECK_MODULES([ECORE_X], [ecore-x >= 0.9.9], [have_ecore_
---
.../Ewl_Engine_Evas_Software_Xcb.h |2 +-
src/engines/evas_software_xcb/Makefile.am |5 ++---
.../ewl_engine_evas_software_xcb.c | 10 ++
src/engines/xcb/Makefile.am|2 +-
src/engines/xcb/ewl_engine_xcb.c
---
src/engines/xcb/ewl_engine_xcb.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/engines/xcb/ewl_engine_xcb.c b/src/engines/xcb/ewl_engine_xcb.c
index cb4251e..a3c656d 100644
--- a/src/engines/xcb/ewl_engine_xcb.c
+++ b/src/engines/xcb/ewl_engine_xcb.
55 matches
Mail list logo
