Re: What happened to the code freeze?
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 is nil. I don't
see how your code could have ever worked.
If there was an issue with the super menu not being set correctly we
need to investigate it. I don't think this is the right fix for it.
Okay, on looking at this more closely now, I think you are right about the
call
to setSupermenu: while decoding. I'm not sure of exactly what was happening
(and
don't have time to debug it at the moment), but the supermenu was nil in all
of
the submenus of our main menu (which is loaded from a nib file). The new call
to
setSupermenu: in insertItem:atIndex: seems to be enough to fix the problem
for
me. My guess now is that the root problem is probably in the nib loading code
for the menu. But the fix as it stands now shouldn't be a problem I think.
Your new change to this code surely wont break things as the old one
did. Still I am not convinced that this is needed. And looking at the
code surely proves this. I believe you that it makes a difference for
you and we need to find out where this difference comes from. If we
don't we not only clutter GNUstep with unneeded code, we will also
surely break things the next time this code gets touched. As a
maintainer I am not only thinking about current code correctness, but
try to assure we can guarantee this over a longer time. Sorry, for
causing you extra work here. On the other hand you would expect me to do
the same for other peoples changes, or for that for my own ones.
Your change in NSMenu looks like this (last line added):
// Set this after the insert notification has been sent.
[newItem setMenu: self];
[[newItem submenu] setSupermenu:self];
And in NSMenuItem we have:
- (void) setMenu: (NSMenu*)menu
{
/* The menu is retaining us. Do not retain it. */
_menu = menu;
if (_submenu != nil)
{
[_submenu setSupermenu: menu];
[self setTarget: _menu];
}
}
In which cases could your code make any difference?
- newItem could not be of class NSMenuItem.
- submenu returned from the method could be different from the slot.
This is not the case for NSMenuItem, so it falls back to the first case.
- setTarget: on the menu item does something strange. This is also not
the case for NSMenuItem.
- There is a redefinition of setMenu: somewhere.
The most likely reason seems to be that we are not dealing with an
NSMenuItem here. Could you please check that?
What is strange when comparing your new patch with your old is that when
NIB loading the new patch will now set the menu twice and the NIB
loading code will set it to nil again and then get it set again via
setSubmenu:forItem:. This all looks so completely wrong. I really would
prefer to understand this before we plaster it over.
I like all the simplifications you did for the menu update for the in
window menu. Why not hide all the details in the
setMenuChangedMessagesEnabled: method? That is have the change passed up
to the super menu and when we are the app menu, do what is needed there?
You will then miss out on some more menu changes, for example when the
main menu doesn't have autoenabled items. Looks like I need to think
about this some more.
Good point. I've moved the call to menuChanged into all of the individual
methods that note the changes.
Great.
The changes to NSApplication I don't like. Why should the application be
concerned about the display of the main menu at all? At least one of
these could be moved into NSMenu -setMain: and perhaps that change could
take care of the second call as well?
Moving the one call into [NSMenu setMain:] is reasonable. Unfortunately, the
call to updateAllWindowsWithMenu: in _didFinishLaunching is necessary, now
that
it isn't being called all the time from [NSMenu update]. Without this call
the
menus never get built. I guess either setMain: isn't being called at launch,
or
it is called too early to be effective.
This is rather sad. Anybody out there with an idea how to resolve this?
We could of course have the main menu listen for the
NSApplicationDidFinishLaunchingNotification notification, but this looks
like overkill for this small issue. But then we already do! We call
_showTornOffMenuIfAny: inthat case. Why not add your code there?
Perhaps we should rename this method then, but it looks like the right
place to me.
Your patch also seems to have an indentation problem are you using tabs?
Sorry, it looks consistent to me. I'm using Notepad++ on Windows. I guess
I'll
have to fiddle with the settings and see if I can get it to conform properly.
Does anyone know the right settings to use?
Us two spaces in stead of tabs or set your tab depth to two, then I wont
notice the difference
Re: opening problems with GWorkspace
Riccardo Mottola wrote: Hi, 1) when using gopen xxx NSworkspace will launch also gworkspace automatically. Strangely, GWorkspace now opens and asks you are you sure you want to quit ?... 2) gopen GWorkspace will open a double copy of it causing grief!!! Could you be more specific what the problem here is? As far as I understand it NSWorkspace has always relied on a workspace application to do most of the work. GWorkspace being the default one. Correct. gopen just uses this mechanism to get it's job done. So yes, starting GWorkspace via gopen could result in it being started twice. No gnustep application should be open twice as far as I can understand... The only thing you report that seems strange is that GWorkspace will quit again. This sounds more like an GWorkspace issue. Possibly, but it did not happen in the past. It does not quit in the sense crash. It asks me politely like I selected Quit from the menu! Nobody else noticed that? I finally managed to reproduce this bug and fixed it in svn. The issue occurred (only) on machines which are slow enough for GWorkspace needing more than 5 seconds to finish launching. The cause of the bug is a subtle error in r29864, where NSRunAlertPanel returns NSAlertFirstButtonReturn instead of NSAlertDefaultReturn when it is run from a non-gui application. This was causing a SIGTERM signal being sent to GWorkspace and a second instance of GWorkspace being started. Note that (thanks to some inexplicable wisdom of Apple) NSAlertFirstButtonReturn is not equal to NSAlertDefaultReturn and that the NSAlertXXXButtonReturn constants are meant to be used only with the NSAlert methods, but not with the old OpenStep dialog functions (and also not with NSAlert's alertWithMessageText:... class method). Incidentally, I noticed during debugging that GNUstep applications do not respond to DO messages while in a modal dialog loop. This means that if the user or a background application attempts to connect to a running application while that application presents a modal dialog, a new instance of the application is launched. If your are using GWorkspace, just put in it into a state where it presents a modal dialog (in the default configuration move a file do a different folder or to the trash), then switch to a terminal and call gopen. After a short delay when the timeout of [conn rootProxy] has expired a new instance of GWorkspace is started. If your are not using GWorkspace, you can use Ink instead. Open its open panel and then use gopen -a Ink to open a rtf document. Again, after a short delay this will start a new instance of Ink. Both behaviors are really annoying. Of course, it is quite unlikely that a user will gopen a document while its application is presenting a modal dialog, but this situation could easily arise with background tools using GWorkspace to launch applications or present documents (or just check the list of running applications!). Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
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 gets set in NSMenuItem +setSubmenu: and
before doing so the code checks that the old super menu is nil. I don't
see how your code could have ever worked.
If there was an issue with the super menu not being set correctly we
need to investigate it. I don't think this is the right fix for it.
Okay, on looking at this more closely now, I think you are right about the
call
to setSupermenu: while decoding. I'm not sure of exactly what was happening
(and
don't have time to debug it at the moment), but the supermenu was nil in
all of
the submenus of our main menu (which is loaded from a nib file). The new
call to
setSupermenu: in insertItem:atIndex: seems to be enough to fix the problem
for
me. My guess now is that the root problem is probably in the nib loading
code
for the menu. But the fix as it stands now shouldn't be a problem I think.
Your new change to this code surely wont break things as the old one
did. Still I am not convinced that this is needed. And looking at the
code surely proves this. I believe you that it makes a difference for
you and we need to find out where this difference comes from. If we
don't we not only clutter GNUstep with unneeded code, we will also
surely break things the next time this code gets touched. As a
maintainer I am not only thinking about current code correctness, but
try to assure we can guarantee this over a longer time. Sorry, for
causing you extra work here. On the other hand you would expect me to do
the same for other peoples changes, or for that for my own ones.
Your change in NSMenu looks like this (last line added):
// Set this after the insert notification has been sent.
[newItem setMenu: self];
[[newItem submenu] setSupermenu:self];
And in NSMenuItem we have:
- (void) setMenu: (NSMenu*)menu
{
/* The menu is retaining us. Do not retain it. */
_menu = menu;
if (_submenu != nil)
{
[_submenu setSupermenu: menu];
[self setTarget: _menu];
}
}
In which cases could your code make any difference?
- newItem could not be of class NSMenuItem.
- submenu returned from the method could be different from the slot.
This is not the case for NSMenuItem, so it falls back to the first case.
- setTarget: on the menu item does something strange. This is also not
the case for NSMenuItem.
- There is a redefinition of setMenu: somewhere.
The most likely reason seems to be that we are not dealing with an
NSMenuItem here. Could you please check that?
What is strange when comparing your new patch with your old is that when
NIB loading the new patch will now set the menu twice and the NIB
loading code will set it to nil again and then get it set again via
setSubmenu:forItem:. This all looks so completely wrong. I really would
prefer to understand this before we plaster it over.
Okay, it looks like I was mistaken about some things. The hazards of coding
after my usual bedtime, I suppose. ;-)
It turns out that the call to setSupermenu: that I added (in the insert
method)
does absolutely nothing. It was the change I made to setSupermenu:self
instead
of setSupermenu:nil during decoding that fixed the problem for me. But I
didn't
look closely enough at the time to fully understand why that fixed it. As
you've
astutely observed, that looks like it ought to cause problems. But what's
actually happening is that everything is already set at that point. I should
have paid more attention to the FIXME comment at that point in the code:
// FIXME: We propably don't need this, as all the fields are
// already set up for the submenu item.
if (sub != nil)
{
[sub setSupermenu: nil];
[self setSubmenu: sub forItem: item];
}
By changing it to call [sub setSupermenu:self] what I achieved was a no-op,
since the supermenu was already set by the earlier call to [self
addItem:item].
The next line was also a no-op, since item's submenu was also set already at
this point. The root of the problem was the call to [sub setSupermenu: nil]
which wiped out the supermenu that was already set correctly!
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 :-)
Did you also read the rest of my mail? What do you think about the
suggestion to move the last menu theme call out of NSApplication?
With that (and the indentation) sorted out you should be able to push
your change.
Fred
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
Re: opening problems with GWorkspace
Am 23.04.2010 17:14, schrieb Wolfgang Lux: Incidentally, I noticed during debugging that GNUstep applications do not respond to DO messages while in a modal dialog loop. This means that if the user or a background application attempts to connect to a running application while that application presents a modal dialog, a new instance of the application is launched. If your are using GWorkspace, just put in it into a state where it presents a modal dialog (in the default configuration move a file do a different folder or to the trash), then switch to a terminal and call gopen. After a short delay when the timeout of [conn rootProxy] has expired a new instance of GWorkspace is started. If your are not using GWorkspace, you can use Ink instead. Open its open panel and then use gopen -a Ink to open a rtf document. Again, after a short delay this will start a new instance of Ink. Both behaviors are really annoying. Of course, it is quite unlikely that a user will gopen a document while its application is presenting a modal dialog, but this situation could easily arise with background tools using GWorkspace to launch applications or present documents (or just check the list of running applications!). This sounds like a very annoying bug to me. And even though we probably have had it for a long time we should try to fix it now that we know about it. Does this mean that DO messages aren't handled at the run loop mode that modal windows run in? I just don't understand enough of that area to suggest a fix. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
What to add to GNUmakefile to compile with a .pch file that came from Xcode project?
Hi, I'm trying to make sure my Xcode project builds in both Xcode and GNUStep. It contains a .pch file containing common includes, which is required to be prefixed to every file compiled during the build. When I add it to the XXX_OBJC_PRECOMPILED_HEADERS as so: Cioccolata_OBJC_PRECOMPILED_HEADERS = Cioccolata_Prefix.pch The build immediately fails with: Making build-headers for framework Cioccolata... Making all for framework Cioccolata... make[1]: *** No rule to make target `/Users/chris/Projects/Mac/Cioccolata/build/GNUStep/obj/PrecompiledHeaders/ObjC/Cioccolata_Prefix.pch', needed by `internal-precompile-headers'. Stop. make: *** [Cioccolata.all.framework.variables] Error 2 Does GNUStep-make handle files with the .pch extension as given by Xcode? What do I need to do to make this work? While my project is still in it's early stages and therefore small I manually copied the contents of the .pch to my .m files and can build the project this way so the only thing I'm stuck on is how to use the .pch. Thanks all, Chris e: ch...@w3style.co.uk t (en): http://twitter.com/d11wtq t (it): http://twitter.com/cosadici ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Patched] What to add to GNUmakefile to compile with a .pch file that came from Xcode project?
I've patched in support for the .pch extension for precompiled headers as used by Xcode. I believe I've also corrected a typo for OBJCC precompiled headers, which was missing a dot in the file extension. gnustep-make-2.2.0.patch Description: Binary data This is working nicely for me. I can use .pch extension or a .h extension; it will do both. For now I'll stick to .h until this patch finds its way into the main project. e: ch...@w3style.co.uk t (en): http://twitter.com/d11wtq t (it): http://twitter.com/cosadici Il giorno 24/apr/2010, alle ore 10.11, Chris Corbyn ha scritto: Hi, I'm trying to make sure my Xcode project builds in both Xcode and GNUStep. It contains a .pch file containing common includes, which is required to be prefixed to every file compiled during the build. When I add it to the XXX_OBJC_PRECOMPILED_HEADERS as so: Cioccolata_OBJC_PRECOMPILED_HEADERS = Cioccolata_Prefix.pch The build immediately fails with: Making build-headers for framework Cioccolata... Making all for framework Cioccolata... make[1]: *** No rule to make target `/Users/chris/Projects/Mac/Cioccolata/build/GNUStep/obj/PrecompiledHeaders/ObjC/Cioccolata_Prefix.pch', needed by `internal-precompile-headers'. Stop. make: *** [Cioccolata.all.framework.variables] Error 2 Does GNUStep-make handle files with the .pch extension as given by Xcode? What do I need to do to make this work? While my project is still in it's early stages and therefore small I manually copied the contents of the .pch to my .m files and can build the project this way so the only thing I'm stuck on is how to use the .pch. Thanks all, Chris e: ch...@w3style.co.uk t (en): http://twitter.com/d11wtq t (it): http://twitter.com/cosadici ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
