So the correct fix is simply to delete that block of code (and the
declaration
and assignment of 'sub' a few lines earlier). I've done that, and also
delete
the other call to setSupermenu: that I had added.
If that works for you, all the better. It is always great to remove some
code
Am 23.04.2010 07:42, schrieb Doug Simons:
On Apr 22, 2010, at 1:41 AM, Fred Kiefer wrote:
You change to set the super menu on a decoded submenu in NSMenu is most
likely wrong. This value already gets set in NSMenuItem +setSubmenu: and
before doing so the code checks that the old super menu
Am 23.04.2010 19:59, schrieb Doug Simons:
On Apr 23, 2010, at 2:21 AM, Fred Kiefer wrote:
Am 23.04.2010 07:42, schrieb Doug Simons:
On Apr 22, 2010, at 1:41 AM, Fred Kiefer wrote:
You change to set the super menu on a decoded submenu in NSMenu is most
likely wrong. This value already
Great that you send this change to the list so we can discuss it in
advance. Anything that touches the system that deep should better be
analysed by many developers even when not in feature freeze mode.
The changes to NSMenuItem are so obvious, why didn't we do it that way
in the first place?
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
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
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
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 fredkie...@gmx.de 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
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
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
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
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
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
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
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
Am 20.04.2010 um 14:30 schrieb Nicola Pero:
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.
Would not make any sense to me.
With about 150 bugs open in the bug tracking system, we
17 matches
Mail list logo
