Re: What happened to the code freeze?
Having many commits during a "feature freeze" is very good as it is supposed to mean that a lots of bugs are being fixed. :-) As far as I can tell none of the recent commits in gui or back is related to any reported bug. [...] Ok - thanks! - that clarifies the problem then :-) I'm sure individual committers would probably disagree or have good arguments why their changes should have gone in - it sounds like we need some simple process to resolve the disagreements and decide what goes in and what doesn't go in at this stage ? ;-) As far as I understand, you're in charge of GUI, so maybe you (and/or Gregory) could propose how you want to manage that ? Maybe patches for GUI must be approved by you before being committed during the feature freeze ? As an outsider, it does seem that GUI needs a few weeks of feature freeze and bug fixing, so I wouldn't give up on that just because it needs to be organized somehow ;-) (btw sorry, I don't mean to interfere - I'll disappear from the discussion of the GUI release freeze after this email) -- For the part I work on (gnustep-make and core makefiles) anyone can make any small fixes they want, but for substantial changes please talk to me before committing (this is always the case though). :-) gnustep-make is quite ready for the 2.4.0 release, except that: * there is this long-standing issue of whether we should link all libraries or not when linking executables. I was planning on making that configurable at ./configure stage (with some reasonable, OS-dependent defaults). It would be good to do this before a release, as it might change how things are linked. On the other hand, I have a feeling it's too late for 2.4.0, so I'll probably do it as the first thing after this release instead. * I haven't looked at how gnustep-make works on Apple at all. I wanted to make sure the apple-apple-apple settings and compiler/linker flags are meaningful and usable - at the moment, I don't think they are as many people reported you have to tweak them in non-obvious ways to use it. If I get some time, I'll try to do this before the release. * I also wanted to look at the Cygwin port, but that may not have time before the release. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
Am 21.04.2010 09:50, schrieb Nicola Pero: > As far as I understand, you're in charge of GUI, so maybe you (and/or > Gregory) could propose > how you want to manage that ? Maybe patches for GUI must be approved by > you before being > committed during the feature freeze ? I'd rather rely on people being careful in what they commit. This used to work in previous years. This time it is different perhaps because we let the release drag on for too long? > As an outsider, it does seem that GUI needs a few weeks of feature > freeze and bug fixing, so I wouldn't > give up on that just because it needs to be organized somehow ;-) Could you please give an explanation of this impression? Was this a general statement that before any gui release we should have such a period or was this based on any specific know limitation of gui? With regards to gui I still don't see you as an outsider, you were the one that committed my first patches to gui and commented on them. In my thinking you still know a lot more about gui than I do. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
As an outsider, it does seem that GUI needs a few weeks of feature freeze and bug fixing, so I wouldn't give up on that just because it needs to be organized somehow ;-) Could you please give an explanation of this impression? Was this a general statement that before any gui release we should have such a period or was this based on any specific know limitation of gui? It's a general statement. The GUI is complicated because of all the interactions. A change in one place might break something somewhere else and which would seem completely unrelated ;-) (I blame the API, but you could conceivably blame the implementation) Because of that, I'd expect the GUI to need even more bug fixing than the rest ? For the non-graphical stuff (gnustep-make, gnustep-base, jigs, SQLClient, WebServer, WebServices, etc) that we use at work, we are very keen on having very stable and bug free releases. We almost don't care about new features. But we need very stable software. So a long bug fixing phase is really good. :-) I would imagine most other users appreciate very stable software too. :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
Am 20.04.2010 23:30, schrieb Nicola Pero: >> Looks like we have more commit right now during code freeze then we >> have at normal times. I would suggest that we give up the idea of >> doing more tests. As long as people cannot stick to a code freeze >> even for a week, > > I thought we were in "feature freeze" - ie, all commits must be bug > fixes as opposed to implementation of new features. A typical > pre-release phase to iron out bugs before a release. :-) I was referring to Gregory's mail from the 9th, there he suggested a code/feature freeze for two weeks. The trouble with the current release is that it was due before FOSDEM, we normal come out with a GNUstep release about twice a year. And this time we really had enough new features and bug fixes to warrant a release, that would be urgently needed to get a new stable release of GNUstep onto current distributions. But then just before FOSDEM Richard started that big reorganisation of base, which was a very good thing to do. I tried to follow this with a rather smaller change to gui and planned for a release right after that. Of course with a bit of time for all applications to adjust to these changes and also for any urgent bug fixes. > Instead, you're suggesting we're in "code freeze" - meaning no > commits at all ? Ie, nothing gets done for weeks ? I've never seen > a project do that. Anyway it would be easy enough to do, we just all > have to stop doing anything. Hmmm. Not sure why that would be > useful ? ;-) Code freeze doesn't mean no "commits at all". It means restricting the commits to important changes that all agree on. Normally this gets done by assigning a release manager that will have to accept and apply patches. We did not do this in GNUstep, but relied on people being careful. I know that you are managing commercial software and that you are quite aware of all these concepts. This means you also know why it is sometimes a good thing to stop doing random changes. In our case it would allow application developers to catch up. While freezing core changes to gdl, Gorm, Gworkspace, GAP and so on are still valid. It would also allow people to test a rather well defined version of GNUstep core on many different platforms. And of course if there are any regressions try to fix them. > Having many commits during a "feature freeze" is very good as it is > supposed to mean that a lots of bugs are being fixed. :-) As far as I can tell none of the recent commits in gui or back is related to any reported bug. Quentin's change clearly addresses a bug so it would be in your definition the only valid candidate for a commit. And although I see this as the most important patch of the year, I think it is to dangerous to apply it now. Something as deep as this needs at least four weeks of testing time, give the slow responses to changes in GNUstep. > With about 150 bugs open in the bug tracking system, we probably > need quite a few weeks of feature freeze / bug fixing to get a good > release. :-) Actually most of the changes done in GNUstep could be counted as bug fixes. What we mostly do is correct cases where GNUstep behaves differently from Cocoa. Event the XIB laoding, the only new feature I added this year, could be seen as a bug fix. Fixing the "GNUstep wont load XIB files" bug :-) > If I am the one who misunderstood and we really are in "code > freeze", please let me know. ;-) > > Probably Gregory should clarify. > > I personally suggest we stay in a "feature freeze / bug fixing only" > phase for a while until the bug count is down and the commits slow > down because there are no more bugs to fix :-) Again, at the moment the bug count is not decreasing, nobody is into fixing old bugs. OK, Richard and you each fixed one bug from the bug tracker during the last week. At that rate we could have a feature freeze for over a year to get the bugs resolved. > Finally, it is quite possible you were referring to some specific > changes that are new features instead of being bug fixes - presumably > in the gui ? If so, you should IMO feel free to point these out, and > even revert them. I am referring to the ongoing changes to gui by Eric and Doug. All of these are valid changes as far as I can tell. They surely fix some behaviour that was annoying enough for them. But all these changes may and did also introduce new issues to others. This is fine in normal development mode, while trying to come up with a stable release it wont help. Perhaps it was an error not to set up any strict release management. I would prefer if we can do without that. This requires that we all need to think about the release and not just our pet issue that is annoying us at this very moment. Having a GNUstep core release soon would be good for the project and for all developers that build on top of GNUstep. This should be our main goal at the moment. And right after the release everybody should go back to committing like crazy. Fred _
What happened to the code freeze?
We probably should have created a branch for the stable state and done the release from there. On Tue, Apr 20, 2010 at 4:39 PM, Fred Kiefer wrote: > Looks like we have more commit right now during code freeze then we have > at normal times. I would suggest that we give up the idea of doing more > tests. As long as people cannot stick to a code freeze even for a week, > we wont have any stable state that is worth testing. As far as we are > aware all the bugs introduced freshly with Richard's and to a lesser > extend my restructuring should be fixed by now. We will find out about > other problems that went in with the recent commits soon enough. > > A the situation isn't improving with more waiting, I think we should > make a release now and then try to get in all the other important stuff > and make another pre-release before the gui/back 1.0. > > Fred > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev > -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
Hello, Fred wrote: > As far as I can tell none of the recent commits in gui or back is > related to any reported bug. > [snip] > I am referring to the ongoing changes to gui by Eric and Doug. All of > these are valid changes as far as I can tell. They surely fix some > behaviour that was annoying enough for them. But all these changes may > and did also introduce new issues to others. This is fine in normal > development mode, while trying to come up with a stable release it wont > help. It's true that the changes I've been submitting aren't in response to bugs in the GNUstep bug system. We are actively fixing bugs in our own application. As an illustration, when we have a bug that affects only the Windows version of our product, I'm pretty sure that it's caused by a problem somewhere in GNUstep, but I don't know for sure until I dig in and debug exactly what's going wrong. This typically takes several hours of debugging, at which point I can see what the problem is, so I fix it. Now, at that point I suppose I could enter a bug on savannah and then mark it as fixed, but I don't really see the point of doing that (and I'm under a lot of time pressure right now, as we are scheduled for a release next week!). So I've just been careful to review my own fixes and try to describe what I'm fixing when I check it in. Since we're in 'code freeze' mode, I hope that someone (maybe more than one someone?) is looking at any changes that are checked in to make sure they look sane, and perhaps think about whether they might have unintended consequences. I'm about to check in a significant fix, that substantially improves performance on Windows (with in-window menus). The change dramatically reduces the frequency of rebuilding the Windows menus. They were rebuilding with every event rather than only when needed. The resulting drag on performance wasn't just an "annoyance" -- it basically made editing text in an NSTextView almost unusable. I've checked my code over carefully, and believe it won't have any negative consequences. As part of this fix, I corrected a bug in NSMenu which was never setting its supermenu ivar correctly, and improved NSMenuItem to only notify its menu that it has changed when something actually changes. It's conceivable that that could impact some other code, but is clearly more "correct" now than its former behavior. The main impact of this change will only be on Windows for applications that use in-window menus. For those applications, there is a small chance that I missed something such that menus will fail to update when they should, now that they're not updating all the time (I don't think so, but it's worth watching out for). I could hold off on submitting this change, but it seems to me like exactly the kind of fix that I (at least) would like to see going in right now. So I plan to check it in as soon as it's validated by some other people here. Please let me know if you see any problems with this change or any others that I submit. We really appreciate the timing of this "feature freeze", by the way, since we are in the middle of a release. Knowing that things are relatively stable and only getting bug fixes is perfect for us right now. And while I'm at it, I'd like to say "THANK YOU" to everyone on the GNUstep team! The more I dig into the code, the more I'm reminded of what an incredible amount of work has gone into it, and despite the bugs (which are frustrating, and are the cause of my digging into the code in the first place) there is an amazing amount of functionality here that is working really well. Hopefully our small contributions will help GNUstep to be even better. Cheers, Doug ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
I believe that "feature freeze" is the correct term and what I was really after when I suggested the freeze. I'm comfortable with any changes that fix or improve existing functionality so long as: 1) they don't add new features and 2) They don't involve drastic refactoring of existing code. GC On Tue, Apr 20, 2010 at 5:30 PM, Nicola Pero wrote: > >> Looks like we have more commit right now during code freeze then we have >> at normal times. I would suggest that we give up the idea of doing more >> tests. As long as people cannot stick to a code freeze even for a week, > > I thought we were in "feature freeze" - ie, all commits must be bug fixes as > opposed to > implementation of new features. A typical pre-release phase to iron out > bugs before > a release. :-) > > Instead, you're suggesting we're in "code freeze" - meaning no commits at > all ? Ie, nothing > gets done for weeks ? I've never seen a project do that. Anyway it would > be easy enough to > do, we just all have to stop doing anything. Hmmm. Not sure why that would > be useful ? ;-) > > Having many commits during a "feature freeze" is very good as it is supposed > to mean > that a lots of bugs are being fixed. :-) > > With about 150 bugs open in the bug tracking system, we probably need quite > a few > weeks of feature freeze / bug fixing to get a good release. :-) > > If I am the one who misunderstood and we really are in "code freeze", please > let me know. ;-) > > Probably Gregory should clarify. > > I personally suggest we stay in a "feature freeze / bug fixing only" phase > for a while until > the bug count is down and the commits slow down because there are no more > bugs to fix :-) > > Finally, it is quite possible you were referring to some specific changes > that are new features > instead of being bug fixes - presumably in the gui ? If so, you should IMO > feel free to point these > out, and even revert them. > > Thanks > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev > -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
Sorry, two of my recent theme-related commits were probably inappropriate to make during the feature freeze (adding an option to disable the inner border in NSScrollView, and moving NSBrowser header drawing to GSTheme). I can revert these if you'd like. Doug: the Windows menu fixes sound great. I was noticing a lot of menu flickering with the WinUX theme, and mousewheel scrolling in Ink was really laggy - I bet your patch will fix those problems. Eric On Wed, Apr 21, 2010 at 11:32 AM, Gregory Casamento < greg.casame...@gmail.com> wrote: > I believe that "feature freeze" is the correct term and what I was > really after when I suggested the freeze. I'm comfortable with any > changes that fix or improve existing functionality so long as: > > 1) they don't add new features and > 2) They don't involve drastic refactoring of existing code. > > GC ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
The feature freeze only includes core (make, base, gui and back). I don't really consider the WinUXTheme (or any of the themes) to be part of the freeze, so your changes are fine where they are. I should have been more concise about the scope of the freeze I wanted in the first place. That would have avoided some of the current confusion. I would like Doug to send the patches he's got in mind to Fred for review and testing. GC On Wed, Apr 21, 2010 at 2:04 PM, Eric Wasylishen wrote: > Sorry, two of my recent theme-related commits were probably inappropriate to > make during the feature freeze (adding an option to disable the inner > border in NSScrollView, and moving NSBrowser header drawing to GSTheme). I > can revert these if you'd like. > Doug: the Windows menu fixes sound great. I was noticing a lot of menu > flickering with the WinUX theme, and mousewheel scrolling in Ink was really > laggy - I bet your patch will fix those problems. > Eric > On Wed, Apr 21, 2010 at 11:32 AM, Gregory Casamento > wrote: >> >> I believe that "feature freeze" is the correct term and what I was >> really after when I suggested the freeze. I'm comfortable with any >> changes that fix or improve existing functionality so long as: >> >> 1) they don't add new features and >> 2) They don't involve drastic refactoring of existing code. >> >> GC -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r30188 - in /libs/back/trunk: ChangeLog Source/winlib/WIN32FontInfo.m
How does this look:
defs = [NSUserDefaults standardUserDefaults];
if ([defs objectForKey: @"GSFontAntiAlias"] != nil
&& [defs boolForKey: @"GSFontAntiAlias"] == NO)
{
logfont.lfQuality = NONANTIALIASED_QUALITY;
}
else
{
logfont.lfQuality = DEFAULT_QUALITY;
}
Settting GSFontAntiAlias to NO forces non-antialiased fonts.
Otherwise, the windows system setting is used.
On Mon, Apr 19, 2010 at 3:38 AM, Fred Kiefer wrote:
> Am 19.04.2010 03:23, schrieb Eric Wasylishen:
> > Author: ericwa
> > Date: Mon Apr 19 03:23:30 2010
> > New Revision: 30188
> >
> > URL: http://svn.gna.org/viewcvs/gnustep?rev=30188&view=rev
> > Log:
> > winlib/WIN32FontInfo.m: Use DEFAULT_QUALITY for fonts
> >
> > Modified:
> > libs/back/trunk/ChangeLog
> > libs/back/trunk/Source/winlib/WIN32FontInfo.m
>
> In back we have the user default GSFontAntiAlias defined that could be
> used to decide whether AA fonts or normal ones should be used.
>
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
Nicola Pero wrote: Looks like we have more commit right now during code freeze then we have at normal times. I would suggest that we give up the idea of doing more tests. As long as people cannot stick to a code freeze even for a week, I thought we were in "feature freeze" - ie, all commits must be bug fixes as opposed to implementation of new features. A typical pre-release phase to iron out bugs before a release. :-) Exactly! I understood the same. Of course some fixes might introduce new bugs, btu this is normal during testing. Instead, you're suggesting we're in "code freeze" - meaning no commits at all ? Ie, nothing gets done for weeks ? I've never seen a project do that. Anyway it would be easy enough to do, we just all have to stop doing anything. Hmmm. Not sure why that would be useful ? ;-) Never head about that, not even at work. A freeze of 1-2 days is possible there, for pure testing, but we can't in opensource do that. Or we might declare a certain weekend to be test weekend, if a couple of people can follow that. With about 150 bugs open in the bug tracking system, we probably need quite a few weeks of feature freeze / bug fixing to get a good release. :-) Yes, we have a lot of bugs. I was speaking with Gregory and it would be nice to have some of these fixed. I personally suggest we stay in a "feature freeze / bug fixing only" phase for a while until the bug count is down and the commits slow down because there are no more bugs to fix :-) Yes, or at least a certain number of bugs have been addressed or explained or posponed. I undertand that this release is long due, but it is a very important release I think. There are many changes, I noticed that many applications need a new release because of adjustments needed. Even smalls tuff, like the header and import cleanup done by Fred. Of course he did a good job, the applications were wrong, but they need to be released soon, so that people don't experience broken applications. There will be some sort of avalanche effect. We must be careful about that, but if done well it will give us exposure and advertisement! They can't call us dead anymore. Finally, it is quite possible you were referring to some specific changes that are new features instead of being bug fixes - presumably in the gui ? If so, you should IMO feel free to point these out, and even revert them. Some of the commits clearly marked fixes. How good they are we must retest. Cheers, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
Hi, * I also wanted to look at the Cygwin port, but that may not have time before the release. I would appreciate that. I think it is currently broken, at least for me. Somebody worked here on the list, but he never replied me when I asked how far he got. Since I consider it broken, I would not put it subject to "feature freeze". If you improve it even partially (atl least to get base working) go on. A very very nice feature fix would be having the instalaltion domain configuration working on windows like on linux! I bet Gregory agrees... Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
A very very nice feature fix would be having the instalaltion domain configuration working on windows like on linux! I bet Gregory agrees... I have already fixed it :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Attempted GORM build on GNUstep/Windows (was: Re: Which bugs to focus on for the release?)
Am 20.04.2010 um 01:06 schrieb Adam Fedor: On Apr 19, 2010, at 11:34 AM, Fred Kiefer wrote: Am 19.04.2010 17:38, schrieb Adam Fedor: Seems to I a great solution to the problem. Perhaps we should also state there, why we don't make it the default (some applications wont work with that setting, as far as I understand) and how to activate, deactivate it later on. OK, this might be to much text for an installation panel, but there seems to be some space left on it. Sure good idea. FYI, I've put a preview release of the Windows installer on the web site, if anyone wants to test it. http://www.gnustep.org/experience/Windows.html I tested the installers the other day. I installed GNUstep System 0.24.2, GNUstep Core 0.24.2 and GNUstep Devel 1.0.0 in that order. Everything worked as expected so far. Then I tried to build GORM on that setup like this: l...@test ~ $ mkdir gorm l...@test ~ $ cd gorm l...@test ~/gorm $ svn co http://svn.gna.org/svn/gnustep/apps/gorm/trunk/ l...@test ~/gorm $ cd trunk/ l...@test ~/gorm/trunk $ make && make install This is gnustep-make 2.2.0. Type 'make print-gnustep-make-help' for help. /GNUstep/System/Library/Makefiles/aggregate.make:48: /GNUstep/System/ Library/Makefiles/Master/serial-subdirectories.make: No such file or directory make: *** No rule to make target `/GNUstep/System/Library/Makefiles/ Master/serial-subdirectories.make'. Stop. What went wrong here? Is there something I missed? regards, Lars ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Attempted GORM build on GNUstep/Windows (was: Re: Which bugs to focus on for the release?)
On Apr 21, 2010, at 4:08 PM, Lars Sonchocky-Helldorf wrote: > > l...@test ~/gorm/trunk > $ make && make install > This is gnustep-make 2.2.0. Type 'make print-gnustep-make-help' for help. > /GNUstep/System/Library/Makefiles/aggregate.make:48: > /GNUstep/System/Library/Makefiles/Master/serial-subdirectories.make: No such > file or directory > make: *** No rule to make target > `/GNUstep/System/Library/Makefiles/Master/serial-subdirectories.make'. Stop. > I'll check the file list. It's possible that was not copied. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r30188 - in /libs/back/trunk: ChangeLog Source/winlib/WIN32FontInfo.m
The code looks OK to me. But is the result what you want to achieve?
I could see us using three cases here. The variable GSFontAntiAlias not
being set means use the standard behaviour, that is DEFAULT_QUALITY. If
it is set to NO, we use NONANTIALIASED_QUALITY and if it is set to YES
we use ANTIALIASED_QUALITY.
Hopefully most people wont even know about this variable so they get the
standard behaviour all the time.
Fred
Am 21.04.2010 20:58, schrieb Eric Wasylishen:
> How does this look:
>
> defs = [NSUserDefaults standardUserDefaults];
> if ([defs objectForKey: @"GSFontAntiAlias"] != nil
> && [defs boolForKey: @"GSFontAntiAlias"] == NO)
> {
> logfont.lfQuality = NONANTIALIASED_QUALITY;
> }
> else
> {
> logfont.lfQuality = DEFAULT_QUALITY;
> }
>
> Settting GSFontAntiAlias to NO forces non-antialiased fonts.
> Otherwise, the windows system setting is used.
>
> On Mon, Apr 19, 2010 at 3:38 AM, Fred Kiefer wrote:
>
>> Am 19.04.2010 03:23, schrieb Eric Wasylishen:
>>> Author: ericwa
>>> Date: Mon Apr 19 03:23:30 2010
>>> New Revision: 30188
>>>
>>> URL: http://svn.gna.org/viewcvs/gnustep?rev=30188&view=rev
>>> Log:
>>> winlib/WIN32FontInfo.m: Use DEFAULT_QUALITY for fonts
>>>
>>> Modified:
>>> libs/back/trunk/ChangeLog
>>> libs/back/trunk/Source/winlib/WIN32FontInfo.m
>>
>> In back we have the user default GSFontAntiAlias defined that could be
>> used to decide whether AA fonts or normal ones should be used.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
