discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Weird color problem with GNUstep/Etoile


From: Fred Kiefer
Subject: Re: Weird color problem with GNUstep/Etoile
Date: Fri, 03 Aug 2007 09:46:18 +0200
User-agent: Thunderbird 1.5.0.12 (X11/20060911)

Andreas Höschler wrote:
>>>> Azalea is started and the fail safe terminal gets its window border as
>>>> expected, but this window title is some weird green, definitely not
>>>> normal.
>>>
>>>   I think it is caused by Azalea, which does *not* use AppKit for
>>> drawing.
>>>   Can you test with OpenBox3 window manager (icculus.org/openbox).
>>>   Azalea is ported from OpenBox3 and use the same drawing mechanism.
>>
>> As mentioned in my other mail, the problem occurs also when I log into
>> a GNOME session and just do
>>
>>     openapp Typewriter  (or any other GNustep application)
>>
>>
>> Azalea is not started in this case so I doubt that it has to do with
>> Azalea. It must have to do with some recent changes in back. GNUstep
>> used to work on Solaris x86. :-(
>>
>> I am just installing the lastest source (from scratch) on a SPARC
>> machine to see whether I get the same problem there.
> 
> OK, I just discovered taht the color problem only occurs when using a
> Sun Ray. I just tried it on the console. No problem. The colors are
> fine. But as soon as I access the machine through Sun Ray Server
> Software I have these weird colors. It seems that the problem only
> occurs when I access server B through a sun ray server software running
> on server A (remote login). That's probably teh reason why I encounetr
> this problem on the Sol x86 box and not on the SPARC. I bet if I
> installed SRS on the Solx86 and accessed it directly the problem would
> not occur.
> 
> So this problem - in opposite to not being able to use GNUstep/Etoile as
> a non-root user - is not very urgent. Nevertheless, if somebody has an
> idea what might cause this...
> 

Looks like you are having a different byte order on the remote display
then the one art detects. As far as I rememeber Alexander Malmberg put
in a solution for this case in 2005. But the comment there leaves some
space for improvement :

    /* If the server doesn't have the same endianness as we do, we need
       to flip the masks around (well, at least sometimes; not sure
       what'll really happen for 15/16bpp modes).  */

See ARTContext initWithContextInfo:

Could you please find out, which colour mode you are using and if you
hit this specific case? Enabling debug output for "back-art" should at
least provide some of the data. (Start your application with
--GNU-Debug=backart)

Cheers,
Fred








reply via email to

[Prev in Thread] Current Thread [Next in Thread]