Re: ANN: GNUstep Base 1.12.0
On Mar 14, 2006, at 3:11 PM, Fred Kiefer wrote: Adam Fedor wrote: The GNUstep Base Library, version 1.12.0, is now available. After a SVN update and a rebuild of make and base, I get the follwoing error message when rebuilding gui (make distclean; ./configure; make; make install): Creating GSspell.service/Resources/Info-gnustep.plist... ././shared_obj/make_services: error while loading shared libraries: libgnustep-base.so.1.12: cannot open shared object file: No such file or directory I don't really have any idea. Perhaps a stale link, but I think that would clear up after a while. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: ANN: GNUstep Base 1.12.0
Adam Fedor wrote: > The GNUstep Base Library, version 1.12.0, is now available. > After a SVN update and a rebuild of make and base, I get the follwoing error message when rebuilding gui (make distclean; ./configure; make; make install): Creating GSspell.service/Resources/Info-gnustep.plist... ././shared_obj/make_services: error while loading shared libraries: libgnustep-base.so.1.12: cannot open shared object file: No such file or directory make[2]: *** [GSspell.service/Resources/Info-gnustep.plist] Fehler 1 make[1]: *** [GSspell.all.service.variables] Fehler 2 make[1]: Leaving directory `/usr/src/svn-gnustep/gnustep/devmodules/core/gui/Tools' make: *** [internal-all] Fehler 2 Any idea, where this comes from and how to work around? Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
On Wed, 22 Feb 2006 18:29:55 +, Richard Frith-Macdonald <[EMAIL PROTECTED]> said: > Maybe all we really need here is FHS support in the make package so > you can opt to install in FHS locations? And lots of publicity so > people know about it. FWIW, Debian is currently handling the FHS issue by using a script to move files around after they are installed by gnustep-make, and using lots of symlinks. (This is just for packages installed by dpkg, installed into the System domain. Packages that are manually installed just using gnustep-make are installed normally.) So under Debian, there is a /usr/lib/libgnustep-base.so.1.11, and other libraries can be found under /usr/lib too. But if gnustep-make had better support for FHS locations, that would be helpful too. -- Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Graphics context in -gui instead of -back or context-bundles
Hi, I have read: http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Images/chapter_7_section_5.html#//apple_ref/doc/uid/TP40003290-CH208-BCICHFGA As far as I was told few weeks ago, it is not possible to draw directly into a bitmap in GNUstep. See "Drawing Directly to a Bitmap" section in the referenced document. As the bitmap output from AppKit/-gui should be the same in all environments (Linux, Windows, OS X,...) I think that the bitmap drawing should be done with one "bitmap drawing backend" for all environments. Would it be possible to pick one bitmap drawing library and use it in -gui? For on-screen drawing, environment native drawing library should be used, so -back will stay as it is. Or ... what about having bundles for each type/class of NSGraphicsContext? Then I one would be able to use, for example, art(screen)+art(bitmap) under linux, GDI(screen)+art(bitmap) under windows and he will get same bitmap results under both environments. What do you think about it? Stefan Urbanek -- http://stefan.agentfarms.net First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
