gnustep-dev
[Top][All Lists]
Advanced

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

Re: NSTabView


From: Fred Kiefer
Subject: Re: NSTabView
Date: Sun, 07 Mar 2010 16:34:44 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.5) Gecko/20091130 SUSE/3.0.0-1.1.1 Thunderbird/3.0

Am 04.03.2010 12:39, schrieb Richard Frith-Macdonald:
> 
> On 1 Mar 2010, at 21:03, Fred Kiefer wrote:
> 
>> I just recompiled Gorm and it looks different here :-)
>> As this is also on a 64bit system the main difference I see is the cairo
>> version. Could you please try a different backend to confirm that it is
>> the cairo backend that causes this behaviour.
>>
>> There are a few places in CarioGState where we differentiate based on
>> the cairo version number. Perhaps a few of these checks are off?
>> I know that GNUstep worked with all the cairo releases that were
>> available for OpenSuse (I had to get it working as I use this backend
>> for years now), but there may be cairo releases where extra bugs need to
>> be worked around.
>>
>> If it turns out, the problem isn't backend relate, it will be much hard
>> to pin it down
>>
>> Am 01.03.2010 00:03, schrieb address@hidden:
>>> It's my own application which shows this behaviour. I do not have a
>>> theme enabled, I am using the cairo backend. Everything is built from
>>> current svn trunk. Gorm shows the same broken behaviour on my machine,
>>> screenshot is attached. I am on Ubuntu 8.04 AMD64, cairo version is 1.6.0.
>>>
>>> Thanks
>>> TOM
>>>
>>> Zitat von Fred Kiefer <address@hidden>:
>>>
>>>> I just tried to reproduce this behaviour and failed to.
>>>> On which application are you seeing this and probably more important,
>>>> which GNUstep backend are you using? Do you have a theme enable?
>>>>
>>>> Am 27.02.2010 18:54, schrieb address@hidden:
>>>>> Looks like NSTabView in trunk is currently buggy. I attached a
>>>>> screenshot to this message. Gorm from svn trunk displays it the same
>>>>> way. Tell me if you need further information.
> 
> I don't know if this is the same thing, but on my system (32bit intel, 
> CentOS-4.5) it seems that NO images are displaying with the Cairo backend at 
> present.
> I don't know how long this has been the case for, since I've been 
> concentrating exclusively on base for the last few weeks, and haven't updated 
> gui/back at all (indeed it's possible that a system update has changed the 
> underlying cairo library or something similar without me noticing since last 
> time I was playing with gui).
> 
> I did think I might have broken proxying in some way (though all the base 
> regression tests still pass) with all the changes I've been making, but if I 
> use the art backend, images display as normal.  I guess the problem could be 
> some change in base anyway, if the cairo backend depends on something which 
> art doesn't.
> 
> The following 'ls' command might tell you something (it doesn't enlighten me 
> at all)...
> 
> $ ls /usr/lib/*cair*
> /usr/lib/libcairo.so        /usr/lib/libpangocairo-1.0.so
> /usr/lib/libcairo.so.2      /usr/lib/libpangocairo-1.0.so.0
> /usr/lib/libcairo.so.2.9.2  /usr/lib/libpangocairo-1.0.so.0.1400.9

Sounds like a different problem to me, but like a very interesting one :-)
With the .so numbers I don't have a clue, which cairo version this
really is. Could you please use pkg-config --modversion cairo to get the
version number the system thinks it has?
GNUstep should be able to display images with all versions of cairo
starting from 1.0 or so. I am currently using cairo 1.8.8.

The next instruction would be to recompile all of GNUstep from scratch,
but I now you are doing this already.

The only change in recent time that could affect you is the one I did on
the 20th of Febuary to adjust the cairo backend to the CGFloat change of
base. This change works correctly on my 64 bit system, but it could be
different on a 32 bit one. Could you please try to compile base (and all
the rest) with the definition of CGFloat turned back to float? If this
changes the behaviour of the cairo backend then we know where to look.




reply via email to

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