Re: Proposal to deprecate Xlib backend
Yen-Ju Chen schrieb: I guess this is the reason why transparency does not work in Cairo backend: cairo backend draw everything directly on xwindow. In -gui, an image is often draw on a hidden window, then composite on the destination. Because cairo backend draw directly on xwindow first, it loses the alpha value. Then when it is composited to the destination, the transparent part becomes the background of the hidden window. I have a copy of cairo backend in Etoile project: http://svn.gna.org/viewcvs/etoile/branches/yjchen/etoile_back/ It basically draw on the x11/XWindowBuffer first as what art backend does. Therefore, it keeps the alpha value for composition. The modification is very little. You can check out README.etoile_back. A simple diff is sufficient to see the difference of source code. There are some minor issues here and there, though. Great, this resolves the transparency issue! I added your changes for this to the official GNUstep cairo backend. I did not take over your changes to x11, on which I need to take another look. You also have a change to add the freetype2 libraries and settings to the configuration. This should not be needed if cairo is configured correctly. Could you please type in pkg-config --libs cairo at a command prompt to see if this includes freetype or not? I also added you endianess change, hope I did get it correct. As you have the unbuffered code commented out yourself, I did not take it over. And the NSClipView change is clearly a hack. We need to resolve the actual issue behind it. With images now drawn transparent you will see that many images get flipped. I will have to take another look into the horrible compositeGState:... method to sort this out. If we are lucky the clip view issue will get resolved by that as well. The next thing to investigate will than be the text drawing, as the metrics seem to be wrong here. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUmakefile and a strange case
On Tuesday 19 December 2006 21:44, Christopher Armstrong wrote: Hi gcc -o account.so -shared Account.os cli.os man.os User.os Group.os LoggedUser.os -L/usr/lib/GNUstep/System/Library/Libraries -lobjc -lgnustep-base scons: done building targets. Note with this you're linking against the gnustep-base library, which includes the NSString class (the missing export in your error messages). I guess you are making use of NSString somehow (either in the constant (@) or non-constant form). Yes, I am using NSString directly ([NSString ...]) and indirectly (@...) many times as well as other GNUstep classes. And since it is a library I am using I am liking with it... anything wrong there ? On Monday 18 December 2006 19:49, José Pablo Fernández wrote: User.m:108: warning: â_OBJC_INSTANCE_0â defined but not used User.m:185: warning: â_OBJC_INSTANCE_1â defined but not used User.m:194: warning: â_OBJC_INSTANCE_2â defined but not used These warnings come with gnustep-base when you use constant strings in the form @something here They seem to be harmless, and its a bug in gcc that should be fixed when the gcc guys get round to it (ask them; check their bug reporting system first). Ok, thank you. ? Any help in any of these problems is appreciated. You said you were compiling a c library. It used to be a c-only library... now it is a obj-c library. This form of a GNUmakefile with GNUstep does not link in gnustep-base. I am not sure what we are talking about really, because... You will want to compile as a normal library ($(GNUSTEP_MAKEFILES)/library.make). ... that is what I included in my GNUmakefile. My current GNUmakefile looks like this: include $(GNUSTEP_MAKEFILES)/common.make LIBRARY_NAME = account account_OBJC_FILES = Account.m cli.m Group.m LoggedUser.m man.m User.m account_OBJCFLAGS = -D_GNU_SOURCE -std=gnu99 -pipe -Wall -ggdb -include GNUmakefile.preamble include $(GNUSTEP_MAKEFILES)/library.make -include GNUmakefile.postamble Please note that what you are doing by putting the library in a different directory is likely to cause problems. The gnustep-base library and the objective-c runtime will somehow need to be in your library export path (ldconfig and friends) for libaccount.so to load properly. I can't avoid this. This library is dloaded by another program which loads all the libraries (modules/plugins) in a certain directory, I have to install my library there and even name it in a special way (no lib). -- José Pablo Fernández [EMAIL PROTECTED] ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
GNUstep packaging by TWW tools
I am not a software engineer so I can't help on swapping out xlib with cairo type of projects. but I want to have a FreeBSD type of packaging build system to maintain GNUstep. make gnustep-core-1.10 will unpack,patch,configure and build gnustep software components. It is very wasteful of compute/time resources to require everyone to compile gcc(with objc) if one is interested about running gnustep. GNUStep LiveCD is good but an easy way to install gnustep onto existing installed OS is even better. For now, I am using Solaris 10 intel for packaging gnustep by TWW tools (R1). The goal is to make installation of gnustep very easy across OS platform. My plan 1. prepare gcc-4.1.1 for Solaris 10 intel (U2, 06/2006 version) first and down port lower version solaris and sparc cpu. bash-3.00# /opt/gcc411/bin/gcc -v Using built-in specs. Target: i386-pc-solaris2.10 Configured with: /opt/build/gcc-4.1.1/configure --enable-nls --enable-threads --disable-maintainer-mode --enable-shared --enable-libgcj --enable-languages=c,c++,objc --datadir=/opt/gcc411/share --with-gnu-as --with-as=/opt/gcc411/i386-pc-solaris2.10/bin/as --with-local-prefix=/opt/gcc411 --prefix=/opt/gcc411 Thread model: posix gcc version 4.1.1 bash-3.00# uname -a SunOS b-solx86-10 5.10 Generic_118855-14 i86pc i386 i86pc bash-3.00# 2. package the gnustep core software(make,base,gui). 3. release package sources 4. Lobby gnustep development community to use TWW tool so TWW CPAM tool can help GNUstep's CPAD. This will be hard because asking people to switch to different tools using different processes. Goal: /opt/bin/pkg-inst gnustep-2.0, will install gnustep-core and gnustep apps automatically. will install gnustep and its depended software clusters. This is a hobby project and subject to my free time. References: R1. http://en.wikibooks.org/wiki/CPAM_with_TWW/User_Guide T.J. Yang _ Experience the magic of the holidays. Talk to Santa on Messenger. http://clk.atdmt.com/MSN/go/msnnkwme008001msn/direct/01/?href=http://imagine-windowslive.com/minisites/santabot/default.aspx?locale=en-us ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUmakefile and a strange case
On 18 Dec 2006, at 22:49, José Pablo Fernández wrote: Hello, I have a strange situation here, it used to be a C library compiled with SCons, but now I am using ObjC and GNUstep and I was recommended to use GNUmakefiles because of the added goodies. Now, I need to create a library, the library should be called account.so (note, not libaccount.so, account.so) and it should be installed on /usr/lib/account/modules/ not on /whatever/Library/whatever. How can I do this ? I think you need an extra rule in the makefile to rename/install the library. The standard makefile will build libaccount.so in the obj subdirectory, so your extra install rule needs to copy that to /usr/ lib/account/modules/account.so Now, this library is dlopened, when I compile it with SCons it is loaded succesfully, when I compile it with GNUmakefile (and copy the file by hand renaming it in the process) I get this error: Error loading module 'account.so': /usr/lib/asterisk/modules/ account.so: undefined symbol: __objc_class_name_NSString Evidently there's something different in how it was linked with the gnustep libraries. Quite possibly, but we would need to see the gnustep make file to know what the problem might be. It should look something like (no promise that this is correct ... just a quick, rough idea from memory): include $(GNUSTEP_MAKEFILES)/common.make LIBRARY_NAME=account account_OBJC_FILES = source.m include $(GNUSTEP_MAKEFILES)/library.make after-install: cp obj/libaccount.so /usr/lib/account/modules/account.so And as a last detail, I get this warnings, what do they mean: User.m:108: warning: ‘_OBJC_INSTANCE_0’ defined but not used User.m:185: warning: ‘_OBJC_INSTANCE_1’ defined but not used User.m:194: warning: ‘_OBJC_INSTANCE_2’ defined but not used That's a harmless compiler bug in some versions of gcc ... best ignored. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
