Re: NSTabView problem
Am 12.08.2010 01:27, schrieb Matt Rice: On Wed, Aug 11, 2010 at 10:19 AM, Fred Kiefer fredkie...@gmx.de wrote: The libffi problem will result in no images being displayed. As this isn't the case for you, this looks like some different issue. I can't remember if it was all images, or just named images that had the libffi problem? It's named images that wont work with a broken libffi. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView problem
On Fri, Aug 13, 2010 at 1:32 AM, Fred Kiefer fredkie...@gmx.de wrote: Am 12.08.2010 01:27, schrieb Matt Rice: On Wed, Aug 11, 2010 at 10:19 AM, Fred Kiefer fredkie...@gmx.de wrote: The libffi problem will result in no images being displayed. As this isn't the case for you, this looks like some different issue. I can't remember if it was all images, or just named images that had the libffi problem? It's named images that wont work with a broken libffi. looking at this, http://coyote.octets.fr/simpleagenda/browser/trunk/CalendarView.m and the _1left, _1right etc, i'm guessing those are the images we're seeing in the screenshot and they are loaded not by name but by file, so i'm guessing that libffi being the problem is still in play. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView problem
Am 13.08.2010 10:48, schrieb Matt Rice: looking at this, http://coyote.octets.fr/simpleagenda/browser/trunk/CalendarView.m and the _1left, _1right etc, i'm guessing those are the images we're seeing in the screenshot and they are loaded not by name but by file, so i'm guessing that libffi being the problem is still in play. This is strange code, why would somebody not use imageNamed: to get an image by its name? As for the broken version of libffi, this only results in drawing problems on 64 bit machines and at least in my cause resulted in images not being drawn at all. In this case it looks like the NSTabView tab border images get drawn at the wrong end of the view (at the bottom instead of the top) and upside down. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView problem
Le vendredi 13 août 2010 à 10:57 +0200, Fred Kiefer a écrit : Am 13.08.2010 10:48, schrieb Matt Rice: looking at this, http://coyote.octets.fr/simpleagenda/browser/trunk/CalendarView.m and the _1left, _1right etc, i'm guessing those are the images we're seeing in the screenshot and they are loaded not by name but by file, so i'm guessing that libffi being the problem is still in play. Except that those images are correctly shown in the calendar on the right in the screenshot so I don't get your reasoning. This is strange code, why would somebody not use imageNamed: to get an image by its name? Because somebody wouldn't know the API ?! Philippe ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView problem
Le vendredi 13 août 2010 à 11:11 +0200, Philippe Roussel a écrit : Le vendredi 13 août 2010 à 10:57 +0200, Fred Kiefer a écrit : Am 13.08.2010 10:48, schrieb Matt Rice: looking at this, http://coyote.octets.fr/simpleagenda/browser/trunk/CalendarView.m and the _1left, _1right etc, i'm guessing those are the images we're seeing in the screenshot and they are loaded not by name but by file, so i'm guessing that libffi being the problem is still in play. Except that those images are correctly shown in the calendar on the right in the screenshot so I don't get your reasoning. Forget that, now I understand and I go hide... Philippe ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView problem
Hi! Related thread on mailing list is here: http://lists.gnu.org/archive/html/gnustep-dev/2010-03/msg00041.html Looks like it began to fail in SVN during March. I do not use specific GNUstep releases, so I am not any help regarding releases which work and which don't. I think I removed the libffi-dev package I had on my system , in order to avoid conflicts with the new one I compiled and installed myself. TOM Zitat von Philippe Roussel p.o.rous...@free.fr: Hi Le vendredi 13 août 2010 à 11:01 +0200, ici...@mail.cg.tuwien.ac.at a écrit : Hi! Actually, one of the symptoms was a broken NSTabView, screenshot attached. Installing libffi 3.0.9 fixed that too. Maybe you're right from the beginning. Do you remember which gnustep gui/back version exhibited this bug ? I've been using the same environment (gcc, libffi etc) for building gnustep on this machine for at least 2 years and it worked well. Philippe ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView problem
Le vendredi 13 août 2010 à 11:45 +0200, ici...@mail.cg.tuwien.ac.at a écrit : Hi! Related thread on mailing list is here: http://lists.gnu.org/archive/html/gnustep-dev/2010-03/msg00041.html Looks like it began to fail in SVN during March. I do not use specific GNUstep releases, so I am not any help regarding releases which work and which don't. I think I removed the libffi-dev package I had on my system , in order to avoid conflicts with the new one I compiled and installed myself. Ok, thanks for all the informations. I guess I'll have to somehow try with a new libffi. Philippe ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView problem [Confirmed libffi problem]
Le vendredi 13 août 2010 à 11:57 +0200, Philippe Roussel a écrit : Le vendredi 13 août 2010 à 11:45 +0200, ici...@mail.cg.tuwien.ac.at a écrit : Hi! Related thread on mailing list is here: http://lists.gnu.org/archive/html/gnustep-dev/2010-03/msg00041.html Looks like it began to fail in SVN during March. I do not use specific GNUstep releases, so I am not any help regarding releases which work and which don't. I think I removed the libffi-dev package I had on my system , in order to avoid conflicts with the new one I compiled and installed myself. Ok, thanks for all the informations. I guess I'll have to somehow try with a new libffi. Done. And it works... Sorry for the noise everybody. Just for the record I had to use the following to configure base : ./configure --disable-xmltest --with-ffi-include=/usr/local/lib/libffi-3.0.9/include --with-ffi-library=/usr/local/lib It would be good if a test could be added to configure so that it would fail with a incompatible libffi. Philippe ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView problem
On Wed, Aug 11, 2010 at 11:40:59PM +0200, Philippe Roussel wrote: NSTabView should itself be flipped but at the moment this isn't done in code as there was a drawing problem for flipped views. Or it could be an issue with a theme. Could you please switch to the default theme if you are using any other? I think I tested with all the themes I had installed with similar results but I will check tomorrow, I just erased everything... I can confirm that the bug is there with the default theme and latest svn. I can test patches easily. Philippe -- Linux, le système qui exploite l'ordinateur pas l'utilisateur ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView problem
Hi Fred, Le mercredi 11 août 2010 à 19:19 +0200, Fred Kiefer a écrit : The libffi problem will result in no images being displayed. As this isn't the case for you, this looks like some different issue. From the picture I would say the the tab border images are drawn to the wrong side of the view. This could be an issue with a flipped view. Yup, it looks like it. NSTabView should itself be flipped but at the moment this isn't done in code as there was a drawing problem for flipped views. Or it could be an issue with a theme. Could you please switch to the default theme if you are using any other? I think I tested with all the themes I had installed with similar results but I will check tomorrow, I just erased everything... Philippe ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView problem
On Wed, Aug 11, 2010 at 10:19 AM, Fred Kiefer fredkie...@gmx.de wrote: The libffi problem will result in no images being displayed. As this isn't the case for you, this looks like some different issue. I can't remember if it was all images, or just named images that had the libffi problem? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView problem
On Tue, Aug 10, 2010 at 02:01:42PM +0200, Philippe Roussel wrote: Hi all, I'm trying to update my GNUstep environment and I'm facing drawing problems, whether I use svn head or the lastest unstable release. Have a look at the attached screenshot. Is anyone else having this problem ? This is a 64 bits build with the cairo backend (I think the same problem happens with the art backend), gcc 4.2.4. And now with the screenshot... -- When Dilbert has a better working environment than you its time to leave attachment: simpleagenda-tabs.png___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView problem
Hi! That's the version of libffi which is shipped with your system compiler, apparently gcc 4.2.4. That version of libffi is clearly out of date. Just download and install libffi 3.0.9 and then configure gnustep-base to use that one. Cheers, TOM Zitat von Philippe Roussel p.o.rous...@free.fr: Hi On Tue, Aug 10, 2010 at 02:35:27PM +0200, ici...@mail.cg.tuwien.ac.at wrote: Hi! Check if you are using an up-to-date version of libffi, namely 3.0.9. Well, I'm not sure I understand that : my package manager tells me I'm using libffi-4.2.4 (gcc version by the way) when libffi homepage gives 3.0.9 as the last version... ldd on SimpleAgenda returns ... libffi.so.4 = /usr/lib/libffi.so.4 (0x7f943b42e000) ... Philippe -- Its always easier short term to pee in the pond than install a toilet - it's just not a good long term plan. Alan Cox ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView problem
On Tue, Aug 10, 2010 at 03:00:49PM +0200, ici...@mail.cg.tuwien.ac.at wrote: Hi! That's the version of libffi which is shipped with your system compiler, apparently gcc 4.2.4. That version of libffi is clearly out of date. Just download and install libffi 3.0.9 and then configure gnustep-base to use that one. Ok, this is boring. The new libffi conflicts with the old version installed by my distribution during gnustep-base configure script, I have to disable xml for the configure script to finish (and I used the libffi options to specify /usr/local/, not the global include and library flags)... What's the relation between libffi and this drawing bug ? A function parameter wrongly interpreted ? Philippe -- The qualities that most attract a woman to a man are usually the same ones she can't stand years later. Murphy's Laws on Sex n°15 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView
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 ici...@mail.cg.tuwien.ac.at: 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 fredkie...@gmx.de: 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 ici...@mail.cg.tuwien.ac.at: 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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView
On 7 Mar 2010, at 15:34, Fred Kiefer wrote: 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? [rich...@centos]$ pkg-config --modversion cairo 1.2.4 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. Yes ... just did it again anyway to be sure. 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. It's already float on 32bit systems (the one I'm having image display problems with is a 32bit system) ... it only gets defined to be double on 64bit systems. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView
Hi, I wonder if the change I made in December to use CAIRO_EXTEND_PAD when drawing images is responsible for this. I just checked now and the cairo docs say CAIRO_EXTEND_PAD is only implemented in 1.6 and later for surface patterns. Maybe try commenting out the two calls to cairo_pattern_set_extend in CairoGState.m? -Eric On 2010-03-07, at 11:58 AM, Richard Frith-Macdonald wrote: On 7 Mar 2010, at 15:34, Fred Kiefer wrote: 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? [rich...@centos]$ pkg-config --modversion cairo 1.2.4 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. Yes ... just did it again anyway to be sure. 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. It's already float on 32bit systems (the one I'm having image display problems with is a 32bit system) ... it only gets defined to be double on 64bit systems. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView
Am 07.03.2010 21:42, schrieb Eric Wasylishen: Hi, I wonder if the change I made in December to use CAIRO_EXTEND_PAD when drawing images is responsible for this. I just checked now and the cairo docs say CAIRO_EXTEND_PAD is only implemented in 1.6 and later for surface patterns. Maybe try commenting out the two calls to cairo_pattern_set_extend in CairoGState.m? -Eric I bracketed these calls with a version check. Let's see whether this helps. As this is a problem I cannot reproduce I am at complete lose here. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView
On 7 Mar 2010, at 21:41, Fred Kiefer wrote: Am 07.03.2010 21:42, schrieb Eric Wasylishen: Hi, I wonder if the change I made in December to use CAIRO_EXTEND_PAD when drawing images is responsible for this. I just checked now and the cairo docs say CAIRO_EXTEND_PAD is only implemented in 1.6 and later for surface patterns. Maybe try commenting out the two calls to cairo_pattern_set_extend in CairoGState.m? -Eric I bracketed these calls with a version check. Let's see whether this helps. As this is a problem I cannot reproduce I am at complete lose here. Yes, thanks to both of you ... that now works fine for me. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView
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 ici...@mail.cg.tuwien.ac.at: 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 fredkie...@gmx.de: 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 ici...@mail.cg.tuwien.ac.at: 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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView
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 ici...@mail.cg.tuwien.ac.at: 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 fredkie...@gmx.de: 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 ici...@mail.cg.tuwien.ac.at: 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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView
Hi! I did a test with the art backend, same result. I set a breakpoint in [ARTContext initializeBackend] to be sure it is actually used. Where is the code located that is responsible for drawing the NSTabView's header? Thanks TOM Zitat von Fred Kiefer fredkie...@gmx.de: 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 ici...@mail.cg.tuwien.ac.at: 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 fredkie...@gmx.de: 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 ici...@mail.cg.tuwien.ac.at: 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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView
[NSTabView drawRect:] Am 01.03.2010 22:39, schrieb ici...@mail.cg.tuwien.ac.at: Hi! I did a test with the art backend, same result. I set a breakpoint in [ARTContext initializeBackend] to be sure it is actually used. Where is the code located that is responsible for drawing the NSTabView's header? Thanks TOM Zitat von Fred Kiefer fredkie...@gmx.de: 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 ici...@mail.cg.tuwien.ac.at: 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 fredkie...@gmx.de: 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 ici...@mail.cg.tuwien.ac.at: 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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView
Hi, just for the record, I'm on Freebsd, x86-ia32, cairo 1.8.8.1 and I cannot reproduce your problem, cairo works for me. Riccardo ici...@mail.cg.tuwien.ac.at wrote: 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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView
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 ici...@mail.cg.tuwien.ac.at: 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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
