Re: different GNUstep questions and comments

[Nicolas Roard]

Le 29 oct. 04, à 12:40, Patrick Middleton a écrit :

> [sorry about this: I'm making progress, but there are lots of little 
> things where it would be useful o know what someone else is seeing.  
> Most of the questions I'm hoping you're going to answer should be 
> one-liners from memory...]
(snip)
> Which README.Windows?  I searched C:\GNUstep for all files with names 
> containing 'readme'; that includes all the source code I have 
> downloaded and expanded in C:\GNUstep\Local\.

sorry, it's README.MinGW (for installing using mingw; for Cygwin, there 
is README.Cygwin ..)

> I think I've found what the problem is -- the backend was configured 
> properly, and I don't need to use the user defaults mechanism to 
> specify which backend to use.  I don't need a window manager.  Most 
> applications don't display any GUI because they are flawed.
>
> #ifdef RANT
> There appears to be no documentation regarding what names can be used 
> when setting the backend.
> I have established that backends appear to be bundles in 
> $GNUSTEP_SYSTEM_ROOT/Library/Bundles , and one should use the name of 
> the relevant bundle, without the .bundle extent.
>
> *Appears* to be no documentation?  Googling for 'defaults write 
> NSGlobalDomain GSBackend' finds some.  This doesn't appear to be in 
> any obvious location, ie, anywhere in the gnustep-gui or gnustep-back 
> projects.
> #endif
>
> I went for the gnustep-examples project, and built that.  
> Calculator.app showed UI; some others did too; most didn't.  The 
> problem is that most of the projects seem to be 
> creating/setting/attaching the main menu in via 
> -applicationWillFinishLaunching: , and this is too late.  Without 
> access to the menu, there's no way to make a well behaved GNUstep app 
> open a document.

actually, you can access it by right-clicking on the window, anyway.

> The NSImage test app wasn't being built; I added it to the 
> GNUmakefile, and by moving the code from 
> -applicationWillFinishLaunching: into a new method -menuSet and 
> calling it from main() before [NSApp run], the app works.
>
> The NSImage test app doesn't look very nice, and shows all sorts of 
> bugs in AppKit and the GDI backend.  Big deal; it works as advertised. 
>  Some of my colleagues have seen it; there have been "oooh!"s and 
> "aaah!"s and "oh."s .

ok :-)

> Questions:
>
> [1] I'm getting lots of compilation errors, eg,
> I found a function declared in objc/encoding.h taking a named argument 
> m:
> char *method_get_nth_argument (struct objc_method *m,
>                                arglist_t argframe,
>                                int arg,
>                                const char **type);
>
> I also found a method, declared twice in NSPort.m:
> - (void)handlePortMessage:(NSPortMessage*)m;
>
> and the compiler generates a cryptic error which (while I forget what 
> it says) concerns the redeclaration of 'm' with different type.  I 
> know what RFM wants to do about this; Google found my an archived mail 
> thread including a posting from Stan Shebs that can be summarised as 
> 'no.'  I'm looking to preserve but comment out redundant argument 
> names in function declarations; where a header (eg 
> AppKit/DSOperators.h) contains incline function definitions, this 
> doesn't work, and I'm editing to use longer, more descriptive argument 
> names that, not being single letters, are unlikely to be redeclared 
> with different type (eg, for that header, 'float g' becomes 'float 
> grayAmount', and 'float *g' becomes 'float *grayAmountP'.
>
> Question: are other people, eg you, seeing this?  What are they/you 
> doing about it?

hm I didn't remember particularly that, but I hadn't the time to rework 
on this windows machine anyway... perhaps something that I missed.
It can be nice to send this kind of comments/questions to 
discuss-gnustep and gnustep-dev, as I'm not exactly the windows 
maintener ;-)

> [2] 'make' and the GNUstep standard makefiles seem to be having a hard 
> time on MinGW.
> The build process seems to be creating a build-products directory with 
> the same name as the project,
> then copying assorted files from the current directory in to it
> then trying to soft-link it to '.'.
> ln seems not to be working.
> 'make clean' seems to be using 'rm -r' instead of 'rm -rf', so the 
> build-products directory persists, and gets copied by the next build

yep, I noticed it and added the f sometimes..

> rm: `Current' is a directory
> ln: `Current': cannot overwrite directory
> make[1]: *** [update-current-symlink] Error 1
> make: *** [EDCommon.build-headers.framework.variables] Error 2
>
> This was especially nasty with ProjectCenter
>
> Question: are other people, eg you, seeing this?  What are they/you 
> doing about it?

Well, you can just modify the GNUmakefile.preamble files (that's what I 
did).
But ProjectCenter and Gorm have other issues when you want to compile 
them on windows at the moment
-- gregory casamento (the gorm's maintener) is trying to make it work.

> [3] Crossplatform -- how do we tell that we're building on or for 
> GNUstep?
> I have lots of code that builds cross-platform, except that so far, 
> the supported platforms are
> #if defined(__WIN32__)  WebObjectsDeveloper 4.5.1 on Windows
> #if defined(__APPLE__)  MacOSX
> #if defined(NeXT)       OPENSTEP4.2/Mach
> #if defined(__svr4__)   WebObjectsDeveloper 4.5.1 on Solaris
>
> In principle it would be nice if __GNUSTEP__ was defined as a 
> consequence of the GNUstep standard makefiles.
> In practice, I'm currently editing to do this:
> #if defined(__WIN32__)
> #if defined(__MINGW32__) || defined(__MINGW__)
> /* GNUstep on Windows */
> #else
> /* WebObjectsDeveloper 4.5.1 on Windows */
> #endif
> #endif
>
> which I think is unsatisfactory -- not least because it'll enrage any 
> passing Cygwin zealots.  Testing for #define's indicating the
> NeXT/Apple ObjC runtime or the GNU one doesn't help; supposing we're 
> compiling C or C++?
>
> Question: what are other people/you doing about this?

good question :-)
I think there's a #define, but I don't remember it right now. It would 
be good to have a document stating this kind of things about 
portability...

> [4] OLE/COM; ActiveX ; etc
> I'm guessing here that integrating COM etc into GNUstep/Windows isn't 
> possible yet.
>
> Question: has anybody got a list of either reasons why it can't be 
> done, or things to do before it can be done?

no idea as well -- I really don't know much about window's programming.
*but*. If OLE/COM/ActiveX has C bindings/API, I think it should be 
possible to use them... I guess.
Actually, what would be neat is to implement the "desktop bundles" idea 
and integrate GNUstep more with the underlying desktop (eg, use 
compatible pasteboard, etc.)

--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
 -Arthur C. Clarke