Re: Issues with nextKeyView chain
Doug Simons wrote: Our application had a crash when deallocating a clipView, because its nextKeyView pointed to an object that had already been freed. On carefully reviewing the code, I discovered that the system is designed such that each view can have _multiple_ next and previous key views. I understand why a view could have multiple _previous_ key views (since it's possible to have several other views all pointing to it as their nextKeyView). But I don't believe a view should ever have more than one _next_ key view. I've checked in a change to NSView.m (r30088) that fixes this problem (part of the issue for us turned out to be caused by ivars being zeroed out at the wrong point during nib loading). But it appears to me that the code could be cleaned up and simplified quite a bit if everyone agrees with my assertion that a view should only have one (or zero) nextKeyView. To begin with, the _nextKeyView ivar could be turned into a direct pointer to the next key view rather than a GSIArray. Also, the code is not well encapsulated right now, as it makes direct changes to ivars of other objects. Does anyone see any reason not to change nextKeyView to a single object? Would someone familiar with that code like to make the change? (In particular, I'm unsure whether there may be other classes besides NSView that might be impacted…) I think you are misunderstanding the code here. Each view already has at most one next and previous key view, which is saved in the first element of the respective arrays. The remaining elements of the arrays are used to keep track of those views that refer to this view as their next and previous key view, respectively. For instance, given the statements [P1 setNextKeyView: V]; [P2 setNextKeyView: V]; [P3 setNextKeyView: V]; [V setNextKeyView: N1]; [V setNextKeyView: N2]; [V setNextKeyView: N3]; you will end up with the following situation (sorry for the poor ASCII art, you'll need a fixed pitch font to view this correctly): +-- nextKV \ P1 -- nextKV --+ | +-- prevKV -- N3 \|/ P2 -- nextKV --- V --- prevKV -- N2 /|\ P3 -- nextKV --+ | +-- prevKV -- N1 \--- prevKV --+ Note that the previous key view of V is P3 and the next key view is N3. The pointers to P1, P2, N1, and N2 must be kept in the previous key and next key view arrays so that the nextKV pointers of P1, P2, and P3 and the prevKV pointers of N1, N2, and N3 can be reset when V is deallocated, which is necessary to prevent crashes of the sort you were experiencing. Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Issues with nextKeyView chain
But it appears to me that the code could be cleaned up and simplified quite a bit if everyone agrees with my assertion that a view should only have one (or zero) nextKeyView. To begin with, the _nextKeyView ivar could be turned into a direct pointer to the next key view rather than a GSIArray. Also, the code is not well encapsulated right now, as it makes direct changes to ivars of other objects. Does anyone see any reason not to change nextKeyView to a single object? Would someone familiar with that code like to make the change? (In particular, I'm unsure whether there may be other classes besides NSView that might be impacted…) I think you are misunderstanding the code here. Each view already has at most one next and previous key view, which is saved in the first element of the respective arrays. The remaining elements of the arrays are used to keep track of those views that refer to this view as their next and previous key view, respectively. For instance, given the statements [P1 setNextKeyView: V]; [P2 setNextKeyView: V]; [P3 setNextKeyView: V]; [V setNextKeyView: N1]; [V setNextKeyView: N2]; [V setNextKeyView: N3]; you will end up with the following situation (sorry for the poor ASCII art, you'll need a fixed pitch font to view this correctly): +-- nextKV \ P1 -- nextKV --+ | +-- prevKV -- N3 \|/ P2 -- nextKV --- V --- prevKV -- N2 /|\ P3 -- nextKV --+ | +-- prevKV -- N1 \--- prevKV --+ Note that the previous key view of V is P3 and the next key view is N3. The pointers to P1, P2, N1, and N2 must be kept in the previous key and next key view arrays so that the nextKV pointers of P1, P2, and P3 and the prevKV pointers of N1, N2, and N3 can be reset when V is deallocated, which is necessary to prevent crashes of the sort you were experiencing. Thanks Wolfgang interesting ... good point and great explanation :-) But what you describe (multiple views with the next key view set to the same view) seems like a programming (and user interface) error, so is it worth complicating the implementation to support it - wouldn't we rather have the implementation try to fix it and keep the next key view loop consistent ? :-) The next key view loop that you describe is problematic for the user when navigating. If you are on P2 and hit 'TAB' to go from P2 to V, then when you hit 'shift-TAB' to go back to P2, the system would unexpectedly send you back to another view (P3 if I read your diagram correctly). That's not good. Really, 'shift-TAB' must undo exactly the navigation action that 'TAB' did, so if TAB goes from P2 to V, then 'shift-TAB' must go from V to P2. I personally use TABs often and get upset when I'm hit by this problem which is typical of low-quality Windowish user interfaces - typically you TAB quickly to get to the view you want, but then often you hit one TAB more than needed and get past it, so you then try to go back to it by hitting 'shift-TAB' and are irritatingly sent to some place totally unrelated in the window. As 'shift-TAB' produces unpredictable results, the only way to get back to where you want to be in a predictable time is then to hit TAB again and again and again hoping that the window loop is closed and after TABbing long enough you'll get back to the start of the window and can then TAB your way back to the view you want (and being careful not to miss it again else you'll have to frantically TAB your way out again). Irritating. :-( I seem to remember that the API was built in such a way as to prevent this from ever happening. IIRC calling setNextKeyView: seems so innocent and localized, but it actually does quite a bit of work in other views to keep the next key view loop consistent. And IIRC 'setPreviousKeyView:' was removed by Apple at some point - that makes it even more obvious that 'setNextKeyView:' is expected to modify things in other views to keep the key view loop consistent. :-) So the situation you describe could (should ?) be made impossible - when you call [P2 setNextKeyView: V];, that would completely undo what [P1 setNextKeyView: V]; did. It would detect that V already has a previous key view, and would terminate that by setting both (V-PreviousKeyView)-NextKeyView and V-PreviousKeyView to nil before starting to configure the new next key view. Then any 'TAB' action would always be undoable by using 'shift-TAB', and the memory management is simpler :-) And I agree with Doug that this thing about views editing internals of other views is not that inspiring/beautiful. An alternative (better ?) API would have the 'next key view' as an NSArray instance variable of the NSWindow, and NSWindow would have the methods to manipulate it. The implementation would then be quite simple and clear, but have obviously a different feeling as information on the
GSObjCRuntime / GDL / GSWeb
Hello folks, I seems that the runtime abstraction layer is being deprecated. I would have expected that the introduction of yet another runtime would actually strengthen the need for the abstraction layer. Yet I appreciate that supporting three runtimes is quite a task. Also the semantics of many underlying concepts of EOF and WebObjects (in particular KVC) have changed so much that it seems hardly feasible to continue to hack the runtime structures to make GDL2/GSWeb work with current gnustep-core / Cocoa. I'm currently considering - forking GDL2 to GDL3 which will not be WO45 compatible yet follow it's concepts as much as feasible. - forking/branching -base for GDL2 but stop supporting Cocoa here - forking/branching -gsweb to be more WO45 compatible and have trunk gsweb adapt to GDL3 and current Foundation/Cocoa ie: WO45 compatiblity -base-wo45 -gdl2 -gsweb-wo45 current: -base -gdl3 -gsweb I need the WO45 compatibility and will spend most of my efforts here. the current projects will lose many of the current hacks and should be what new projects would use. @Manuel/@David: Are you still actively using GSWeb and how much do you rely on WO45 compatibility... i.e. if I fork/branch as I described would you be interested in the WO45 compatibility branch or the branch that tracks the current developments. Cheers, David -- David Ayers - Team Austria Free Software Foundation Europe (FSFE) [] (http://www.fsfe.org) Join the Fellowship of FSFE! [][][] (https://fsfe.org/join) Your donation powers our work! || (http://fsfe.org/donate) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GSObjCRuntime / GDL / GSWeb
On 9 Apr 2010, at 19:13, David Ayers wrote: I seems that the runtime abstraction layer is being deprecated. Is it? I would have expected that the introduction of yet another runtime would actually strengthen the need for the abstraction layer. Yet I appreciate that supporting three runtimes is quite a task. As far as I am aware, we are still providing GSObjCRuntime. We are also supporting the new OS X 10.5 runtime APIs and slowly rewriting GSObjCRuntime to use this, rather than poke runtime data structures directly, but I didn't think we were removing it. We still use it for mixins and so on. David -- Send from my Jacquard Loom ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Code/Feature freeze starting next friday...
Am 09.04.2010 20:06, schrieb Gregory Casamento: I propose that we freeze the code to all new features on the trunk before the release starting next friday (4/17). The freeze should be in place for a week or two so that we can find bugs and correct them prior to the release planned for either this month or early next month. Looking over the ChangeLog files of base and gui (Yes, another good use of these files that would be annoying to be replaced with an SVN command), I would say that we are in feature freeze mode for almost two weeks now for both libraries. OK, my header changes could and did break applications including these headers, but tit really wasn't a functionality change. From my point of view we could aim at an earlier release date. The issues I expect with the new release aren't that much in the core code itself, but all the applications using GNUstep should be checked to see how much adjustment is needed there. Or are there any important feature changes pending, I am not aware of, that should go in until next Friday? Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Code/Feature freeze starting next friday...
On 9 Apr 2010, at 22:37, Fred Kiefer wrote: Am 09.04.2010 20:06, schrieb Gregory Casamento: I propose that we freeze the code to all new features on the trunk before the release starting next friday (4/17). The freeze should be in place for a week or two so that we can find bugs and correct them prior to the release planned for either this month or early next month. Looking over the ChangeLog files of base and gui (Yes, another good use of these files that would be annoying to be replaced with an SVN command), Because 'svn log | more' is much more effort to type than 'more ChangeLog'? Not entirely sure I understand that logic... I would say that we are in feature freeze mode for almost two weeks now for both libraries. OK, my header changes could and did break applications including these headers, but tit really wasn't a functionality change. I think I'm inclined to agree. I thought we were already in feature freeze mode, so I've been holding off breaking things (which, as you know, is my hobby). Refactoring the run loop code is next on my TODO list, and I want to do that just after a release so I have lots of time to fix it before real people try using the code. From my point of view we could aim at an earlier release date. The issues I expect with the new release aren't that much in the core code itself, but all the applications using GNUstep should be checked to see how much adjustment is needed there. I think the important thing is not the feature freeze, so much as the pre-release testing. Clang flags quite a few warnings when compiling -gui at the moment, and it's worth spending a little time before the release checking how many of these are real problems. A few come from our protocols not adopting the NSObject protocol, and some come from sending messages to forward-declared classes. There are quite a few instances where objects are passed into format strings with %x, which is only correct on ILP32 or ILP64 platforms, not on LP64 or LLP64 (e.g. Linux or Windows on x86-64). These should be %p. There was one case where an integer was passed as %@, but I think this is fixed now. There are also a few if statements with empty bodies, for example GSToolbarView.m lines 346 and 363. Looking at the code, these appear to be bugs, which should be fixed. There are lots of warnings where TEST_RETAIN() is used and the result is ignored. These are important, because they can lead to subtle bugs where an object returns something other than self from -retain. There are also some strange problems with RETAIN(super) and RELEASE(super). For some reason, the fact that these expand to [(super) retain] and not [super retain] breaks clang. This is a clang bug, but it would be nice if we could compile cleanly anyway. It seems that these macros are superfluous anyway, because, if we're in a -retain method (which is the only place that they're used), we are obviously running in a mode when -retain and -release messages should be sent... Or are there any important feature changes pending, I am not aware of, that should go in until next Friday? I'm happy to start the feature freeze today. If anyone has big blobs of uncommitted code, we probably don't want them dumping it into the repository just before we start pre-release testing... David -- Sent from my IBM 1620 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GSObjCRuntime / GDL / GSWeb
On 9 Apr 2010, at 21:12, David Chisnall wrote: On 9 Apr 2010, at 19:13, David Ayers wrote: I seems that the runtime abstraction layer is being deprecated. Is it? Some parts of it ... I would have expected that the introduction of yet another runtime would actually strengthen the need for the abstraction layer. Yet I appreciate that supporting three runtimes is quite a task. As far as I am aware, we are still providing GSObjCRuntime. We are also supporting the new OS X 10.5 runtime APIs and slowly rewriting GSObjCRuntime to use this, rather than poke runtime data structures directly, but I didn't think we were removing it. We still use it for mixins and so on. Essentially we now have *two* runtime abstraction layers, since we now have the new code you provided from Etoile to wrap the GNU runtime and emulate the Apple Objc2 runtime API. So, I want to use that new API for all the basic functionality, while retaining GSObjCRuntime functions for more complex stuff which does not have a simple, fairly direct equivalent in the Apple API. That avoids us having two abstraction layers to maintain, and means that it's easier to port Apple code to run on GNUstep (and even easier for people to write GNUstep code using apple books and online resources). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Code/Feature freeze starting next friday...
On 9 Apr 2010, at 22:37, Fred Kiefer wrote: Am 09.04.2010 20:06, schrieb Gregory Casamento: I propose that we freeze the code to all new features on the trunk before the release starting next friday (4/17). The freeze should be in place for a week or two so that we can find bugs and correct them prior to the release planned for either this month or early next month. Looking over the ChangeLog files of base and gui (Yes, another good use of these files that would be annoying to be replaced with an SVN command), I would say that we are in feature freeze mode for almost two weeks now for both libraries. OK, my header changes could and did break applications including these headers, but tit really wasn't a functionality change. From my point of view we could aim at an earlier release date. The issues I expect with the new release aren't that much in the core code itself, but all the applications using GNUstep should be checked to see how much adjustment is needed there. Riccardo has a reproducible problem with gdnc on Hurd, and I've encountered something which might be the same/related thing (which I couldn't reproduce on my own machine) when I tried to upgrade systems at work. It looks like some networking issue, perhaps a descriptor leak etc, and really needs to be tracked down and fixed before a release. The fact that I can't yet reproduce it on my system means that it might take a while to get it fixed :-( ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
