Re: [Gnustep-cvs] r27911 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m
On 27 Feb 2009, at 09:03, Fred Kiefer wrote: Now you left me puzzled. Which menu items get duplicated by my reorganisation code? I tried to reproduce this with FlexiSheet and Bean and I am very sure that each item only appears once. In FlexiSheet I see an issue with the missing German language string for Services as there we have a German menu NIB, but otherwise everything is as expected. On the contrary your code is duplicating the quit menu item, but that isn't that bad, is it? I am not sure about the separator items. I fully agree that they don't look great in our current drawing style. But the idea of structuring even a vertical a menu seems correct to me. We could try to replace the separator item drawing with something that just displays a vertical or horizontal line, this will make the menu item size computation a bid harder, but surely looks a lot better. Now we have two differing opinions. How to proceed from here? Are there any other points of view out there? Well, I'm really not that familiar with the issue and don't really understand the nature of the disagreement (assuming there is a real disagreement and not just a misunderstanding). The points I'm clear on are ... 1. duplication of code for handling menu rearrangement. I think I wrote the original code for this for switching between vertical and horizontal menus, but that' so long ago I don't remember any detail. It sounds like Greg wrote different code to do a similar job at the point when a nib is unarchived. I guess everyone things there should be only one version. 2. Now that menus support spacer items, there is debate about how to handle them ... I'm sure the original rearrangment code predates spacers, so it's not surprising if it doesn't do a good job with them. 3. Some code has some other glitches in it that I don't understand/ follow? On the issue of spacers ... I think we need to keep the spacer items in the menu so that we retain all the information about them and can therefore switch between horizontal and vertical layouts repeatedly and consistently. However, horizontal and vertical menus should draw them differently of course. A simple option would just be for the drawing code to treat the as if they don't exist when drawing a vertical menu ... ie make them occupy zero space on screen. Visually this would probably be best. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Top level menu spacers [was: Re: [Gnustep-cvs] r27911 ...]
Am Freitag, den 27.02.2009, 09:24 + schrieb Richard Frith-Macdonald: On 27 Feb 2009, at 09:03, Fred Kiefer wrote: I am not sure about the separator items. I fully agree that they don't look great in our current drawing style. But the idea of structuring even a vertical a menu seems correct to me. We could try to replace the separator item drawing with something that just displays a vertical or horizontal line, this will make the menu item size computation a bid harder, but surely looks a lot better. Now we have two differing opinions. How to proceed from here? Are there any other points of view out there? On the issue of spacers ... I think we need to keep the spacer items in the menu so that we retain all the information about them and can therefore switch between horizontal and vertical layouts repeatedly and consistently. However, horizontal and vertical menus should draw them differently of course. A simple option would just be for the drawing code to treat the as if they don't exist when drawing a vertical menu ... ie make them occupy zero space on screen. Visually this would probably be best. I agree that spacers at the top level (actually independent of whether vertical or horizontal layout) are unexpected to me. Yet I'm not sure whether they should categorically be disabled, or whether they could be tagged as automatically merged by the layout engine and only automatically disable their display when they are thus tagged. This would allow explicit spacers to remain. [I'm not sure whether it's really worth the work but I just wanted you to consider it.] Now the rendering of top-level spacers should probably be a theme hook. And as long as we have the NeXTstep UI as default, maybe someone could check what top-level spacers looked like in OPENSTEP. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Fix for NSURLProtocol
Hi all, The attached patch allows me to use NSURLConnection with an URL needing authentication. Without that change the connection never receives data and ends right after didReceiveAuthenticationChallenge: is received and treated by the delegate. This patch may not be the right fix, I didn't looked closely. Hope this helps, Philippe Index: Source/NSURLProtocol.m === --- Source/NSURLProtocol.m (révision 28000) +++ Source/NSURLProtocol.m (copie de travail) @@ -1085,8 +1085,10 @@ [request setValue: auth forHTTPHeaderField: @Authorization]; [self stopLoading]; + ASSIGN(this-request, request); DESTROY(this-cachedResponse); [self startLoading]; + return; } } } ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
