[bug #25105] recursive notifications on text field exit when changing theme

[Fred Kiefer]

Update of bug #25105 (project gnustep):

                  Status:                    None => In Progress            
             Assigned to:                    None => FredKiefer             

    _______________________________________________________

Follow-up Comment #1:

To make the discussion about this issue easier, here a backtrace of the
recursion:

#27 0x0804af1d in -[ThemeDocument activate] (self=0x81ab608,
    _cmd=0x8061590) at ThemeDocument.m:212
#28 0x0804f95d in -[ThemeDocument setInfo:forKey:] (self=0x81ab608,
    _cmd=0x8066cb8, value=0x9051f40, key=0x80666cc) at ThemeDocument.m:881
#29 0x08059689 in -[MiscElement textDidEndEditing:] (self=0x82c5cf8,
    _cmd=0xb7f355c0, aNotification=0x9051ed8) at MiscElement.m:141
#30 0xb7923179 in -[NSNotificationCenter _postAndRelease:] (
    self=0x8078878, _cmd=0xb7b37588, notification=0x9051ed8)
    at NSNotificationCenter.m:1070
#31 0xb7923a8e in -[NSNotificationCenter
postNotificationName:object:userInfo:] (self=0x8078878, _cmd=0xb7b37590,
name=0xb7f261a4, object=0x8427990,
    info=0x0) at NSNotificationCenter.m:1129
#32 0xb7923945 in -[NSNotificationCenter postNotificationName:object:] (
    self=0x8078878, _cmd=0xb7f358a8, name=0xb7f261a4, object=0x8427990)
    at NSNotificationCenter.m:1109
#33 0xb7e13764 in -[NSTextView resignFirstResponder] (self=0x8427990,
    _cmd=0xb7f18840) at NSTextView.m:1490
#34 0xb7dca3c0 in -[NSWindow makeFirstResponder:] (self=0x844ec08,
    _cmd=0xb7f11780, aResponder=0x844ec08) at NSWindow.m:3081
#35 0xb7dadf84 in -[NSView removeSubview:] (self=0x844ed00,
    _cmd=0xb7f11758, aView=0x841e898) at NSView.m:879
#36 0xb7dadefc in -[NSView removeFromSuperview] (self=0x841e898,
    _cmd=0xb7f18418) at NSView.m:853
#37 0xb7dc341b in -[NSWindow setContentView:] (self=0x844ec08,
    _cmd=0x8062398, aView=0x841e898) at NSWindow.m:1126
#38 0x08051a28 in -[ThemeElement selectAt:] (self=0x82c5cf8,
    _cmd=0x8066c30, mouse={x = 321, y = 432}) at ThemeElement.m:69
#39 0x0805900b in -[MiscElement selectAt:] (self=0x82c5cf8,
    _cmd=0x8061360, mouse={x = 321, y = 432}) at MiscElement.m:71
#40 0x0804af59 in -[ThemeDocument activate] (self=0x81ab608,
    _cmd=0x8061590) at ThemeDocument.m:214
#41 0x0804f95d in -[ThemeDocument setInfo:forKey:] (self=0x81ab608,
    _cmd=0x8066cb8, value=0x9037380, key=0x80666cc) at ThemeDocument.m:881
#42 0x08059689 in -[MiscElement textDidEndEditing:] (self=0x82c5cf8,
    _cmd=0xb7f355c0, aNotification=0x9037340) at MiscElement.m:141
#43 0xb7923179 in -[NSNotificationCenter _postAndRelease:] (
    self=0x8078878, _cmd=0xb7b37588, notification=0x9037340)
    at NSNotificationCenter.m:1070
#44 0xb7923a8e in -[NSNotificationCenter
postNotificationName:object:userIn---Type <return> to continue, or q <return>
to quit---
fo:] (self=0x8078878, _cmd=0xb7b37590, name=0xb7f261a4, object=0x8427990,
    info=0x0) at NSNotificationCenter.m:1129
#45 0xb7923945 in -[NSNotificationCenter postNotificationName:object:] (
    self=0x8078878, _cmd=0xb7f358a8, name=0xb7f261a4, object=0x8427990)
    at NSNotificationCenter.m:1109
#46 0xb7e13764 in -[NSTextView resignFirstResponder] (self=0x8427990,
    _cmd=0xb7f18840) at NSTextView.m:1490


This is just the main part, beside that a lot of other thing happen, as
setting the main menu...

What is happening: The text view, where you type in the author looses focus,
it calls resignFirstResponder which according to the comments there does what
it has to do:

  /* NB: According to the doc (and to the tradition), we post this
     notification even if no real editing was actually done (only
     selection of text) [Note: in this case, no editing was started,
     so the notification does not come after a
     NSTextDidBeginEditingNotification!].  The notification only means
     that we are resigning first responder status.  This makes sense
     because many objects inside the gui need this notification anyway
     - typically, it is needed to remove a field editor (editable or
     not) when the user presses TAB to move to the next view.  Anyway
     yes, the notification name is misleading. */

It posts a NSTextDidEndEditingNotification notification. Which causes the
misc element to set some info on the theme document. This gets the theme
document to activate the theme, this sounds wired to me, but is application
logic and beyond question here.
This results in the same misc element being selected and its super class
implementation removes the contents view of the window but setting that very
view as the contents view of some inspector. 
As it happens our text view is a subclass of this contents view and now
looses first responder state. As far as GNUstep is involved all of this sounds
rather normal. The only thing that I could do in GNUstep is to prevent
replacing a contents view by itself. I will try this and see if it helps. 

But really do you think what your application is doing is the right thing? Do
you still think so after looking that backtrace over?


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?25105>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/