[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Getting Started w/ GNUSTEP-GUI
From: |
Stephen Sebeny |
Subject: |
Re: Getting Started w/ GNUSTEP-GUI |
Date: |
Tue, 31 Jan 2006 02:28:45 -0500 |
User-agent: |
Microsoft-Entourage/11.1.0.040913 |
Hi Again,
> Probably this failed because /etc/GNUstep was not writable by the
> user who installed GNUstep.
> If they want to build from source they can configure the make and
> base packages to use an alternative location for the config file
Ya, it seems the support folks who set this up built it on one machine
then moved it to the login servers and just missed the /etc/GNUStep.cong
file completely.
> I've rebuilt everything and used the /usr/local/GNUstep/GNUstep.conf
> path as the configuration file in the gnustep-make package (so the rest
> of the packages should pick that up). I have updated all of the login
> servers. Please try this and let me know if there is a problem.
[sebeny@omicron:~/gui_test]> ls
GNUmakefile main.m
[sebeny@omicron:~/gui_test]> gmake
Making all for app GUITestApp...
Creating GUITestApp.app/....
Compiling file main.m ...
Linking app GUITestApp ...
Creating GUITestApp.app/Resources...
gmake[1]: *** Warning: File `GUITestApp.app' has modification time in the
future (2006-01-31 02:09:15.01342 > 2006-01-31 02:09:15.0127364)
Creating GUITestApp.app/Resources/Info-gnustep.plist...
Creating GUITestApp.app/Resources/GUITestApp.desktop...
gmake[1]: warning: Clock skew detected. Your build may be incomplete.
[sebeny@omicron:~/gui_test]> openapp GUITestApp.app
Can't find the required application: GUITestApp.app!
[sebeny@omicron:~/gui_test]> openapp ./GUITestApp.app
ld.so.1: GUITestApp: fatal: ure-text: open failed: No such file or directory
ld.so.1: GUITestApp: fatal: ure-text: audit initialization failure: disabled
ld.so.1: GUITestApp: fatal: libgnustep-gui.so.0.10: open failed: No such
file or directory
Killed
So, it looks like that one config file fixed one problem with the
openapp tool, but now there are some others. Does anyone have any advice on
these? (Building and running Foundation tools works fine.)
Also, regarding building a tool that links against the AppKit someone
said:
> It is possible as long as you don't use classes/methods which depend
> on resources that the application expects to find in its bundle...
> look in the Tools subdirectory of the gui library package for examples.
> Basically your GNUmakefile.premable needs to add flags to let your
> tool find the gui headers and to add '-lgnustep-gui' to the
> libraries it links with.
I was wondering if anyone can be a bit more specific on this. Of course
if its a tool I'm not going to use anything that expects to be able to find
bundle resources, I get that. Basically what I want to do is make a tool
that is given a path to a folder as a command line argument, then loads all
the images in that folder into NSImages, then extracts features from those
images. That is, it loops over all the pixels of the image with the getPixel
method of NSBitmapImageRep and pulls out color histogram data and writes it
to a file. I all ready have a program that does this on a Mac, but I need to
move it to Solaris, thus trying to get the GnuStep GUI stuff set-up since
the NSImage classes are in the GUI library. Although, I just noticed that
the GnuStep version of the NSBitmapImageRep class seems to be missing the
getPixel method?! Am I missing something here? That seems like *THE*
essential method of the class, and it just doesn't have it. (?)
As for the tool linking against the GUI library, you mentioned some
examples in the "Tools subdirectory of the gui library package." What do you
mean by this? Where are these? I haven't download anything, as I don't have
the privileges to set this type of stuff up on the machines that I'm using.
I have to rely on the support folks to install stuff. Is there some place on
the web I can get these examples that show a tool using AppKit? Basically I
just need to see the makefile, or how to compile manually (where I can just
specify the -lgnustep-gui) rather than using those complicated makefiles.
-----
Stephen M. Sebeny
sebeny.1@osu.edu