On 4/2/06, Laurence Vanek [EMAIL PROTECTED] wrote:
Didier -
Found the problem. I had a value set for DISPLAYMANAGER in
/etc/sysconfig/desktop file. Once this was commented out I was able to
get enlightenment to start using gdm following the rest of your advice
in this thread.
I see. My
On Sat, 01 Apr 2006 22:30:23 -0500 Jason Tackaberry [EMAIL PROTECTED] babbled:
Hi raster,
On Sun, 2006-04-02 at 10:27 +0900, Carsten Haitzler wrote:
how are you using it? using ecore_evas? are you using the update region
callback by hand (not ecore_evas) ? i am looking at the code here -
Eterm-0.9.4
+ /usr/bin/gzip -dc /home/didier/rpmbuild/SOURCES/Eterm-0.9.4-20060402.tar.gz
+ tar -xvvf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd Eterm-0.9.4
+ tar -xvvf -
+ /usr/bin/gzip -dc /home/didier/rpmbuild/SOURCES/Eterm-bg-0.9.4.tar.gz
+ STATUS=0
+ '[' 0 -ne 0 ']'
++ /usr/bin/id -u
+ '[' 500 = 0
Hi all,
I would like to start a new discussion regarding E features.
During the past time I usually use 2 different languages for input in
my work. This languages are english and russian. So, in order to be
able to switch between them I use setxkbmap program of the X11. I wrote
a script
I got it. There's a permission problem in CVS. A chmod +x of the file
fixed the problem. I had the same thing with Etk's gendoc. The
permission setting has to be fixed in CVS.
--
With kind regards,
Didier.
Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe
Didier F.B
Hi all
This is an update of ja.po for e16 which reflects
the contents of 0.16.8.1.
---
Thank you for telling me the truth. --- HAL9000 in 2010
Yasufumi Haga [EMAIL PROTECTED]
http://homepage3.nifty.com/peterpan/
fingerprint:0EFA 299A BC32 7D68 1FEF BA2B 804E 9B15 C4F0
Hi Aleksej,
Could you send your script which you use to setup your environment? I think
most developers could get a better understanding of the situation by just
looking at your script.
Also, Perhaps some of this could incorporated as an input method configuration?
-Stafford
On Sun, 2 Apr
On Sun, 2006-04-02 at 10:27 +0900, Carsten Haitzler wrote:
how are you using it? using ecore_evas? are you using the update
region callback by hand (not ecore_evas) ? i am looking at the
code here - if u ask for EVAS_ENGINE_BUFFER_DEPTH_ARGB32 depth -
it will zero out the alpha channel
The api functions:
evas_coord_world_*_to_screen and evas_coord_screen_*_to_world
should be used for converting between canvas coords and viewport
coords.
That of course should have read:
The api functions:
evas_coord_world_*_to_screen and evas_coord_screen_*_to_world
Dmitry Antipov wrote:
Hello all,
This patch against imlib2 1.2.2 tries to utilize new GCC feature -
__attribute__((visibility(x))) (see http://gcc.gnu.org/wiki/Visibility
for more details about this). Most of __imlib* functions are marked
with __attribute__((visibility(hidden))), with the
Yasufumi Haga wrote:
Hi all
This is an update of ja.po for e16 which reflects
the contents of 0.16.8.1.
Thanks, committed :)
/Kim
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications
Hi raster,
On Sun, 2006-04-02 at 16:15 +0900, Carsten Haitzler wrote:
are you using BGRA in freevo too? you know that invovles evas having to do a
byteswap for all rendering as its the opposite color-order to evas's
internals?
(which is ARGB) ?
Evas's internals are ARGB? Well isn't that a
On Sun, 2006-04-02 at 15:18 +, [EMAIL PROTECTED] wrote:
In your example, you have an output size of (640, 480), and
a viewport at (0,0) of size (800, 600).
You then create a rectangle object of *canvas* coordinate
size (700, 50) and move it to the *canvas* position (0, 300).
I
On Sun, 2006-04-02 at 13:40 -0400, Jason Tackaberry wrote:
Pixel values still wrong, but at least now it's zeroing the alpha at the
old location after object move.
So there seems to be two separate problems with BGRA32 here.
Just to follow up, I saw raster had committed a few related changes
---BeginMessage---
Didier Casse wrote:
On 4/2/06, Laurence Vanek [EMAIL PROTECTED] wrote:
Didier -
Found the problem. I had a value set for DISPLAYMANAGER in
/etc/sysconfig/desktop file. Once this was commented out I was able to
get enlightenment to start using gdm following the rest of
On Sun, 2006-04-02 at 15:18 +, [EMAIL PROTECTED] wrote:
In your example, you have an output size of (640, 480), and
a viewport at (0,0) of size (800, 600).
You then create a rectangle object of *canvas* coordinate
size (700, 50) and move it to the *canvas* position (0, 300).
On Sunday, 02 April 2006, at 19:46:37 (+0800),
Didier Casse wrote:
I got it. There's a permission problem in CVS. A chmod +x of the
file fixed the problem. I had the same thing with Etk's gendoc. The
permission setting has to be fixed in CVS.
Sorry, this is my fault. We had some permissions
Michael Jennings wrote:
On Sunday, 02 April 2006, at 19:46:37 (+0800),
Didier Casse wrote:
I got it. There's a permission problem in CVS. A chmod +x of the
file fixed the problem. I had the same thing with Etk's gendoc. The
permission setting has to be fixed in CVS.
Sorry, this is
Here is that script I use :
#!/bin/sh
f=`setxkbmap -print | grep xkb_symbols | awk '{printf $4}' | cut -d '+' -f 2`
if [ $f = us ]; then
setxkbmap -model compaqik13 -layout ru -variant basic
elif [ $f = us(basic) ]; then
setxkbmap -model compaqik13 -layout ru -variant basic
elif [ $f =
Jason Tackaberry writes:
Evas's internals are ARGB? Well isn't that a hell of a thing.
I thought for sure when I was looking at the raw data from
evas_object_image_data_get() that it was in BGRA pixel format.
(Note that I'm on intel, which is little endian, so BGRA32 has
BGRA pixel
I've encountered another bug. This one exists with ARGB32 but not
BGRA32.
If the row stride given in the info struct (dest_buffer_row_bytes) is
not equal to the output width * 4, nothing ends up getting rendered to
the canvas (it is completely empty).
See attached test case.
Cheers,
Jason.
On Sun, 02 Apr 2006 12:51:26 -0400 Jason Tackaberry [EMAIL PROTECTED] babbled:
Hi raster,
On Sun, 2006-04-02 at 16:15 +0900, Carsten Haitzler wrote:
are you using BGRA in freevo too? you know that invovles evas having to do a
byteswap for all rendering as its the opposite color-order to
On Sun, 2 Apr 2006 23:30:31 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled:
Jason Tackaberry writes:
Evas's internals are ARGB? Well isn't that a hell of a thing.
I thought for sure when I was looking at the raw data from
evas_object_image_data_get() that it was in BGRA pixel
On Sun, 02 Apr 2006 15:28:38 -0400 Jason Tackaberry [EMAIL PROTECTED] babbled:
On Sun, 2006-04-02 at 13:40 -0400, Jason Tackaberry wrote:
Pixel values still wrong, but at least now it's zeroing the alpha at the
old location after object move.
So there seems to be two separate problems
On Mon, 2006-04-03 at 08:51 +0900, Carsten Haitzler wrote:
there was - i never finished off the BGRA code for the buffer canvas :) i
never
used it - and i think this was the first case of someone using it :)
And only purely by accident, because I thought BGRA32 was the native
pixel format.
On Sun, 02 Apr 2006 19:34:06 -0400 Jason Tackaberry [EMAIL PROTECTED] babbled:
I've encountered another bug. This one exists with ARGB32 but not
BGRA32.
If the row stride given in the info struct (dest_buffer_row_bytes) is
not equal to the output width * 4, nothing ends up getting rendered
On Mon, 2006-04-03 at 12:22 +0900, Carsten Haitzler wrote:
stop finding all the corner cases i don't ever use! :):):)
ROFL. :)
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web
On Sun, 02 Apr 2006 23:19:43 -0400 Jason Tackaberry [EMAIL PROTECTED] babbled:
On Mon, 2006-04-03 at 12:22 +0900, Carsten Haitzler wrote:
stop finding all the corner cases i don't ever use! :):):)
ROFL. :)
and fixed now in cvs... :) (basically another case i wasn't handling - when
dest
28 matches
Mail list logo
