Re: gnustep on windows
On 3 Mar 2008, at 23:41, Christopher Armstrong wrote: Hi Fred On 04/03/2008, at 7:06 AM, Fred Kiefer wrote: Just one comment on this impressive patch. You seem to override some system colour methods on NSColor to use the Windows colour settings in GNUstep. This is the wrong approach to do so. You should be generating a new system colour list and send that via the themeDidActivate notification of your theme. That way even system colours loaded from a NIB file would be displayed correctly. All you have to do is create the list: list = [[NSColorList alloc] initWithName: @"System"]; and to add your colours to it: [list setColor: Win32ToGSColor(COLOR_WINDOWTEXT) forKey: @"controlTextColor"]; Thanks, this looks like just what I was looking for. I know what I was doing was a hack but I wasn't sure about the way around it. Also, I'm not sure what patch version you have but I was thinking of introducing another theme notification called GSThemeDidUpdate or the like, which is sent the first time a theme is updated, or by a theme whenever it changes its appearance and requires widgets to be updated. Another alternative is sending GSThemeDidActivate every time a theme needs to update its appearance. This is even if the theme itself does not change but needs to change what it looks like. It is necessary, because Windows uxtheme (or a similar adapted theme engine) could undergo a theme change, and we would need to update our appearance. I think you should use GSThemeDidActivate when windows changes it's theme ... because you are activating a new theme (windows has changed to a new theme). The notification is meant to mean that a them has become active, not that a theme engine has changed (for instance, pixmap based themes are likely to all use the same theme software, just different images). Essentially this notification tells the gui controls that they should refresh any cached theme information and redraw themselves ... having two notifications doing the same thing would seem more trouble than it's worth. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
On Mar 3, 2008, at 1:40 PM, Riccardo wrote: A newer stable release should be done indeed. Adam? That's up to Gregory, et. al. Do we have any goals for the next stable release? gui 1.0? That last stable release, I didn't start backporting patches until six months afterwards, when it was impossible to catch up. This time I'll be more on top of things, so the branches should track better, hopefully. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
On Mar 3, 2008, at 9:28 AM, Hubert Chathi wrote: I was intending on tracking the GNUstep unstable branch in Debian experimental, but we currently have some unresolved issues regarding ffcall/libffi. I think tracking unstable would be a good idea. Are you having general problems with libffi/ffcall or on a particular platform? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep-make and C++ projects...
On Mar 3, 2008, at 5:30 PM, Nicola Pero wrote: PS: The variables used to specify C++ and ObjC++ flags in gnustep- make are currently called CCFLAGS and OBJCCFLAGS (eg, ADDITIONAL_CCFLAGS, etc), not CXXFLAGS and OBJCXXFLAGS. Not sure why. If CXXFLAGS and OBJCXXFLAGS are more "natural" to C++ developers, we could set up a new terminology I guess; it would also be nice to be consistent with the new CXX variable used for the C++ compiler (I couldn't use CC there since it's already in use for the C/ObjC compiler). ;-) Oh, yeah, I was just talking about vanilla gmake--those are the variables used by its built-in rules (see gmake -p). I was not too familiar with what gnustep-make actually uses. I guess it doesn't matter, as long as you don't rely on the built-in rules. Sorry for the confusion, and thanks for clarifying this. -Tim ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep on windows
Hi Fred On 04/03/2008, at 7:06 AM, Fred Kiefer wrote: Just one comment on this impressive patch. You seem to override some system colour methods on NSColor to use the Windows colour settings in GNUstep. This is the wrong approach to do so. You should be generating a new system colour list and send that via the themeDidActivate notification of your theme. That way even system colours loaded from a NIB file would be displayed correctly. All you have to do is create the list: list = [[NSColorList alloc] initWithName: @"System"]; and to add your colours to it: [list setColor: Win32ToGSColor(COLOR_WINDOWTEXT) forKey: @"controlTextColor"]; Thanks, this looks like just what I was looking for. I know what I was doing was a hack but I wasn't sure about the way around it. Also, I'm not sure what patch version you have but I was thinking of introducing another theme notification called GSThemeDidUpdate or the like, which is sent the first time a theme is updated, or by a theme whenever it changes its appearance and requires widgets to be updated. Another alternative is sending GSThemeDidActivate every time a theme needs to update its appearance. This is even if the theme itself does not change but needs to change what it looks like. It is necessary, because Windows uxtheme (or a similar adapted theme engine) could undergo a theme change, and we would need to update our appearance. Christopher Armstrong [EMAIL PROTECTED] ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep-make and C++ projects...
>> It would be nice if gnustep-make was to automatically do all of >> this. Not that sure how to decide when to use C++ linking (is it >> when only CC_FILES are non-empty and all the other xxx_FILES are >> empty ?) and how to best automate it. Suggestions from C++ users >> are welcome. > > Wouldn't it be whenever CC_OBJS or OBJCC_OBJS is non-empty? Yes - good suggestion - I implemented it in trunk. :-) Thanks PS: The variables used to specify C++ and ObjC++ flags in gnustep-make are currently called CCFLAGS and OBJCCFLAGS (eg, ADDITIONAL_CCFLAGS, etc), not CXXFLAGS and OBJCXXFLAGS. Not sure why. If CXXFLAGS and OBJCXXFLAGS are more "natural" to C++ developers, we could set up a new terminology I guess; it would also be nice to be consistent with the new CXX variable used for the C++ compiler (I couldn't use CC there since it's already in use for the C/ObjC compiler). ;-) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Summer of Code 2008
I think SoC would be a good thing to get into this year. We need to gain momentum and SoC is a good way to get the word out as well as get some people interested in GNUstep. Later, GJC -- Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Fred Kiefer <[EMAIL PROTECTED]> To: GNUstep Developer Sent: Monday, March 3, 2008 4:19:06 PM Subject: Summer of Code 2008 I just noticed that application for Google's Summer of Code started today. We have until 12th of March to submit our application as mentoring organization. I am not saying that we have to, the result from the projects last year were a bit below of what we expected. On the other hand, in the end the KVO and KVB code that was done during SoC started our implementation in that area. Without that it might have taken us another year to even look at it. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Summer of Code 2008
I just noticed that application for Google's Summer of Code started today. We have until 12th of March to submit our application as mentoring organization. I am not saying that we have to, the result from the projects last year were a bit below of what we expected. On the other hand, in the end the KVO and KVB code that was done during SoC started our implementation in that area. Without that it might have taken us another year to even look at it. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
Hi, On 2008-03-02 21:00:53 +0100 Hubert Chathi <[EMAIL PROTECTED]> wrote: Yes, Debian currently tracks the stable branch. My understanding was that the purpose for stable was to provide a stable ABI for application developers to target. But I'm hearing more about applications that need the unstable branch to compile. (PRICE, and simpleagenda.app, at least.) So, is it better to track stable or unstable at this point? I cannot tell for sure, but PRICE had little changes since the past release, so it should compile. It misses some printing stuff which was probably added later. I guess it can be backported to stable. A newer stable release should be done indeed. Adam? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep on windows
Christopher Armstrong wrote: > Hi Paul > > Thought I'd chime in on the conversation :-). > >>> When programming with GNUstep you will be working against the GNUstep >>> drawing API, not cairo or GDI. It is true that the implementation of >>> this API for cairo is more complete, but even that may be changed. >> Oh, I know, but it doesn't make a lot of sense to maintain multiple >> backends when one will serve. Also GDI vector drawing looks ugly and >> Cairo looks nice... so I'd prefer to use Cairo. That way, my results >> should be pretty much the same on Windows and Linux. > > I agree with using cairo. From what I can ascertain, they call GDI where > possible and do custom drawing where GDI fails to support it - > effectively a GDI backend of their own. If we can just pass a HDC to > cairo and let it do the drawing, this means we can take advantage of > their improvements to *their* GDI backend. > > They're API has already been integrated with GNUstep at one point so it > shouldn't be difficult to do it again. > >>> You might be talking about [Camaelon][1] (spelling is important). >> I have read a bit about Camaelon, but my understanding is that it's a >> theming engine rather than an API. I also have the impression that it's a >> bit slow because it's pixmap-based. I was looking at the Narcissus theme >> engine, but the developer made the comment that his patch to NSScroller >> to enable theming of the scroller was rejected because it didn't conform >> to the theming API that had been planned. I haven't really been able to >> find out much about this API, however. > > I'm not sure what theming API had been planned, but I'm sure if you were > to write one it would be accepted. I think there is alot of ideas > floating around but none have been really fleshed out as code yet. The > current API and theming code in GNUstep itself suggests using a grid of > pixmaps for each UI element that are stretched and tiled onto the GUI. > > I have been toying with theming on and off for the past couple of years. > I haven't really got that far, but I'm some way to developing an API. I > have been trying to integrate Windows theming into GNUstep, which isn't > all that hard really, its just trying to understand the MS documentation > and work out the best way to match it to GNUstep. The hard part is doing > the Windows 2000 theming because Microsoft doesn't store this as a > theme, but rather requires you to paint it yourself. > > Please find attached what I have at the moment (be warned: it is a bit > messy and incomplete). Your free to play with it or pitch any questions > you have about it to me. > Just one comment on this impressive patch. You seem to override some system colour methods on NSColor to use the Windows colour settings in GNUstep. This is the wrong approach to do so. You should be generating a new system colour list and send that via the themeDidActivate notification of your theme. That way even system colours loaded from a NIB file would be displayed correctly. All you have to do is create the list: list = [[NSColorList alloc] initWithName: @"System"]; and to add your colours to it: [list setColor: Win32ToGSColor(COLOR_WINDOWTEXT) forKey: @"controlTextColor"]; Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep on windows
Xavier Glattard wrote: > I just made some small changes in CairoContext.m > The zip file has been updated : > http://amstradstuff.free.fr/GNUstep/back-win32cairo.zip > > Cairo backend and Cairo/Glitz backend can be build and run. > With Calculator and Gorm: > Cairo backend : > Text is Ok. Most bitmaps are ugly (transparency ?). > With Gorm : many error log from GNUstep and Cairo. A black window. > Glitz backend : > everything is display in ONE window... > > I can put all this highly experimental stuff in the repository > if you thing that may be useful. > Just before you put it into SVN, could you please rewrite all the licenses to be LGPL 3 and remove the Windows line endings from the headers? Otherwise putting that code into SVN would be fine by me. Perhaps we should add a big warning that it is unsupported and currently not working? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
Stefan Bidigaray wrote: > Debian Unstable (Sid) tends to only track stable packages of anything! > The so called "unstable" Debian branch is just unstable due to package > problems, but the packages in it are generally the latest stable > (assuming there's someone maintaining them). Yes, that is usually true. (A few packages may track the unstable branch, e.g. the GNUMail package, which is based off a daily snapshot. But for the most part, packages in Debian sid track stable branches.) Occasionally, unstable branches can be tracked in Debian experimental. I was intending on tracking the GNUstep unstable branch in Debian experimental, but we currently have some unresolved issues regarding ffcall/libffi. By the way, if anyone wants to help with GNUstep packages, we can always use help. -- Hubert Chathi <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep on windows
I just made some small changes in CairoContext.m The zip file has been updated : http://amstradstuff.free.fr/GNUstep/back-win32cairo.zip Oops... looks like someone beat me to the punch. Great minds think alike, eh? At any rate, I showed my results, and they aren't ideal. Does anyone have ideas? Paul ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
gnustep on windows
Ok, I've downloaded the patch and worked on merging the changes in CairoContext.m with the latest version (so pdf and ps output would still work) as well as cleaning up a few minor style things. It now compiles, but I get garbage when I try to run Gorm, and the GNUstep test appears to freeze. I can't find obvious errors in my modification, so is there some code somewhere else that's a problem? Here's the modified CairoContext.m: http://www.mediafire.com/?n2s1stkmu9c and here's the result I get for Gorm: http://www.mediafire.com/?ianwbjdsdxs Does anyone have any suggestions? Paul ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
On Sun, 02 Mar 2008 11:51:01 +0100, Riccardo <[EMAIL PROTECTED]> said: > Hi, > On 2008-03-02 00:18:47 +0100 Adam Fedor <[EMAIL PROTECTED]> wrote: > It's time for another release. I'll make an unstable release of the core >> libraries late next week. I also plan a stable base release, but I >> will not make a stable release of the gui libraries, unless there is >> some important patch the someone wants there (or better yet, patch >> the stable branch yourself so I don't have to do it). > I know of no blocking issues, I should probably give a compile test on > gcc 2.95 in the next days, just to be sure. About stable, since I > gather Debian tracks stable (?) it would be nice to have some of the > printing stuff backported to stable: PRICE doesn't compile against > current debian packages. But it is just my guess: htey have an > reasonably up to date base, but a horrid old gui and I thought it was > that they track stable. Yes, Debian currently tracks the stable branch. My understanding was that the purpose for stable was to provide a stable ABI for application developers to target. But I'm hearing more about applications that need the unstable branch to compile. (PRICE, and simpleagenda.app, at least.) So, is it better to track stable or unstable at this point? Hubert (with his Debian Developer hat on) -- Hubert Chathi <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
gsweb on amd64
(my original CC: did not work) Hi folks, I just compiled one of my web apps for NetBSD 4.0/amd64 Everything seems to work so far :) I did not try gdl2, but my own simple DB layer just works... Dave ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: Next release
> It's time for another release. Btw, gnustep-make is also ready for release - I suppose it could be called 2.0.5. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
