Follow-up Comment #2, bug #25592 (project gnustep):
Yes: the display is Ok when GSBackHandlesWindowDecorations = true (native
win32 borders - shoudn't it be the other way round??).
When the backing store is 'non retained', the display is right too. You may
test this with this tool :
Hello Nicola,
What would be needed to support these Makefile fragments?
(In particular gsapp.bundle)
Cheers,
David
Am Montag, den 16.02.2009, 11:00 + schrieb Nicola Pero:
Author: nicola
Date: Mon Feb 16 12:00:10 2009
New Revision: 27885
URL:
These makefile fragments are supported in the sense that I kept them working
over the years. :-)
But I always wonder if anyone is using them. I also wonder if there is any
difference with a bundle ... except for a few variables with a different name ?
Is it worth merging these into bundles ?
Update of bug #9445 (project gnustep):
Open/Closed: In Test = Closed
___
Follow-up Comment #6:
I implemented parallel build stuff
Thanks
Hola Adam!
I was able to go a bit further, but not all the way (below my last
error)...
I'd also try to install gdl2 through macports, and while it tries to
build gnustep-gui it breaks (error number 2 below)...
can there be a conflict?
can you suggest a better/easier way to install gnustep
Hola Adam y David,
I went directly to NSGraphicsContext.m and comment some conditional
lines (where the _gcontext variable appear) and I was able to compile
all the way up to Gorm... however, macports is not finding GDL2
anywhere... could you please be so kind to point me to a site where I
Am Montag, den 16.02.2009, 13:16 +0100 schrieb Nicola Pero:
These makefile fragments are supported in the sense that I kept them working
over the years. :-)
But I always wonder if anyone is using them. I also wonder if there is any
difference with a bundle ... except for a few variables
The simplest way on the mac is to do this:
1. Download the latest source from ftp://ftp.gnustep.org
gnustep-make and gnustep-base in pub/gnustep/core
gnustep-dl2 in pub/gnustep/libs
For the packages gnustep-make, gnustep-base and gnustep-dl2, in order,
do the following
cd into the package
Ricardo Strausz wrote:
error 2 (from macports):
Fermat:~ sa$ sudo port -v install gnustep-gui
--- Building gnustep-gui
Error: Target org.macports.build returned: shell command cd
On 16 Feb 2009, at 16:35, Fred Kiefer wrote:
Ricardo Strausz wrote:
NSGraphicsContext.m: In function 'GSCurrentContext':
NSGraphicsContext.m:93: warning: instance variable '_gcontext' is
@private; this will be a hard error in the future
NSGraphicsContext.m: In function '+[NSGraphicsContext
Update of bug #25571 (project gnustep):
Assigned to:None = stoyan
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25571
___
Follow-up Comment #7, bug #25505 (project gnustep):
My nvidia driver is version 180.22 and my cairo 1.8.0. This could be enought
to explain the difference. Or it may even be the X server (Suse 11.1 comes
with 7.4).
At least we can now rule out the missing SHM as the only reason for my
problem.
Follow-up Comment #5, bug #24111 (project gnustep):
indeed, I get:
checking for custom shared objc library... NONE
checking whether objc has thread support... no
checking whether we should use native ObjC exceptions... not requested by
user
checking for the GCC version... version: 4.1
but it is
Follow-up Comment #1, bug #25602 (project gnustep):
ADDITIONAL_INCLUDE_DIRS +=-I/usr/local/include/libpng
that fixes it for me
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25602
Follow-up Comment #5, bug #25552 (project gnustep):
it works now on FreeBSD for me.
I did not check windows though, can you report, Fred? In any case if it is
still broken you should probably open a specific bug for windows, since it
must be something different.
Update of bug #25552 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #6:
Good :-)
Thanks
___
Reply to this
Follow-up Comment #10, bug #25033 (project gnustep):
I do use gcc 2.95 since ever on OpenBSD and it works. I am recompiling
right now.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25033
URL:
http://savannah.gnu.org/bugs/?25603
Summary: NSRulerView fails to compile (incompatible type of
argument)
Project: GNUstep
Submitted by: rmottola
Submitted on: Mon 16 Feb 2009 11:19:08 PM GMT
Category: Gui/AppKit
Update of bug #25602 (project gnustep):
Assigned to:None = fedor
___
Follow-up Comment #2:
I'd prefer updating configure to check for the location of png.h. I have a
patch for that I'll
Follow-up Comment #1, bug #25603 (project gnustep):
No relevant changes in NSRulerView since months, since it used to compile,
the problem must be elsewhere, possibly in base?
___
Reply to this item at:
Update of bug #25602 (project gnustep):
Status:None = Ready For Test
___
Follow-up Comment #3:
Can you try it now from svn?
___
Follow-up Comment #2, bug #25603 (project gnustep):
In an ObjC call, the first two arguments are the object and the selector, so
arg 3 is the first argument you see in the method call. Version is supposed to
be an integer, but I don't know why that would cause an error. It's
definitely wrong
Update of bug #13383 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #8:
Being worked on as #25602
Thanks
___
Update of bug #24111 (project gnustep):
Category: Base/Foundation = Makefiles
___
Follow-up Comment #6:
It seems to me that the critical part in the output you quote is:
checking whether objc has
Update of bug #25603 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #25528 (project gnustep):
Status: Need Info = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #16:
I close this bug
Update of bug #24923 (project gnustep):
Status:None = Need Info
Assigned to:None = FredKiefer
___
Follow-up Comment #4:
Still waiting for
27 matches
Mail list logo