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 indi
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
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
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 "f
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
>
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 annoyin
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
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
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 woul
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;
}
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 m
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
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
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 sett
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-subd
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 ANTIALIA
16 matches
Mail list logo
