Remove FusedSilica?

2010-04-07 Thread Fred Kiefer 
While going through the internal GNUstep headers I noticed that we still
have the place holders for CoreGraphics in there that Adam added a few
years ago. Now with an ever more complete implementation of CoreGraphics
in opal these seem obsolete to me. Should we just remove them?
The only drawback I can think of is an application that did not directly
request CoreGraphics by importing a header, but relied on AppKit
providing it. But such an application was wrong in the first place and
it is also highly unlikely that any application could work with the the
minimal subset of CoreGraphics that was implemented in FusedSilica. All
of these operations have direct mappings in AppKit and the application
should be changed to use these.

Another limitation is that Opal will only work with the cairo backend
and I doubt that will will currently work with a combination of AppKit
and CoreGraphics calls, but hopefully this gets resolved soon.

We don't have to remove it now. This is something I would like to
resolve before the 1.0 release of gui.

Fred


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Remove FusedSilica?

2010-04-07 Thread Quentin Mathé 

Le 7 avr. 2010 à 09:38, Fred Kiefer a écrit :

While going through the internal GNUstep headers I noticed that we  
still

have the place holders for CoreGraphics in there that Adam added a few
years ago. Now with an ever more complete implementation of  
CoreGraphics

in opal these seem obsolete to me. Should we just remove them?


I think so. I doubt anybody has ever used them.
I even never realized that FusedSilica was a CoreGraphics  
implementation.


Quentin.



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Problem with Gorm and GDL2

2010-04-07 Thread David Ayers 
I contemplated on relying on precompiled headers and converting
everything in GDL2 to import Foundation.h (AppKit.h where applicable)
but decided against it for now since I currently cannot test correctly.
(I'm having VM issues)

I hope that this is fixed now...  Thanks for the report!

Cheers,
David

Am Montag, den 05.04.2010, 21:26 +0200 schrieb Fred Kiefer:
> It could well be that this problem was triggered by the current
> restructuring of the gui includes. All applications will need to take
> care to include or rather import all the needed bits from base or gui
> themselves. Up to now a full include of Foundation.h would often happen
> when certain gui headers were included.
> 
> Am 01.04.2010 19:48, schrieb German Arias:
> > Just now I upgraded my system. But currently, my problem is that GDL2
> > can't compile, I get the error
> > 
> > EOPopUpAssociation.m:155: error: ‘NSInternalInconsistencyException’
> > undeclared (first use in this function)
> > EOPopUpAssociation.m:155: error: (Each undeclared identifier is reported
> > only once
> > EOPopUpAssociation.m:155: error: for each function it appears in.)
> > 
> > That, I think, is a problem on NSException class.
> > 
> > David Ayers escribió:
> >> Hello Germán,
> >>
> >> Am Mittwoch, den 24.03.2010, 18:59 -0600 schrieb Germán Arias:
> >>  
> >>> I have GDL2 palette in Gorm, but when I start Gorm I get the error:
> >>>
> >>>  objc runtime: cannot find class GDL2KVCNSObject
> >>>
> >>> and Gorm crash.
> >>> 
> >>
> >> Could you please open a bug report for this?
> >>
> >> I currently don't have a setup to test this myself.
> >>
> >> In GDL2 we had infrastructure in place to insure that our KVC categories
> >> had precedence to those in the GNU and NeXT runtimes.
> >> I /believe/ (but haven't checked) that the libobjc2 runtime may not
> >> support those techniques based on Categories in method lists.
> >>
> >> Richard was so kind to attempt to work around based on classes with the
> >> goal that this works with all runtimes.  So please state which runtime
> >> you are using.
> >>
> >> The class is implemented in EOControl/EOKeyValueCoding.m. It is a root
> >> class.  Maybe something in Gorm or in the runtime you are using is the
> >> reason why the class cannot be found.
> >>
> >> You can assign the bug to GDL2 for now, but I wouldn't be surprised if
> >> it is a runtime bug related to the fact that this is a root class.
> >>
> >> Cheers,
> >> David
> 


-- 
David Ayers - Team Austria
Free Software Foundation Europe (FSFE) []  (http://www.fsfe.org)
Join the Fellowship of FSFE! [][][]  (https://fsfe.org/join)
Your donation powers our work! ||   (http://fsfe.org/donate)



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Compiler warnings building GNUstep gui

2010-04-07 Thread Jens Ayton 
On Apr 6, 2010, at 13:03, David Chisnall wrote:
> On 6 Apr 2010, at 09:24, Fred Kiefer wrote:
>> 
>> NSRulerMarker.m:189: warning: ‘-retain’ not found in protocol(s)
> 
> I see this a lot in code ported from OS X.  I'm not sure exactly why it's an 
> error for us and not on OS X, but all of the Cocoa protocols are treated as 
> conforming to the NSObject protocol (I've not checked if they explicitly do, 
> or if the compiler just pretends that they do).

It's explicit.

-- 
Jens Ayton



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev