bugGNUstep - Bugs: bug #23336, NSWindow...

Group
 
 

bug #23336: NSWindow initWithContentRect:sytleMask... apparently called twice when loading from .gorm file

Submitter:  Gregory John Casamento <gcasa>
Submitted:  Fri 23 May 2008 08:57:27 PM UTC
   
 
Category:  Gui/AppKit Severity:  4 - Important
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  gcasa
Open/Closed:  In Test
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 24 May 2008 03:17:43 PM UTC, comment #8: 

Please test these current changes.  I'm moving this one to "In Test" since this specific issue is addressed and opening another one regarding the changes to GSWindowTemplate and the handling of the defer flag so that the issues may be tracked separately.


Gregory John Casamento <gcasa>
Group administrator
Sat 24 May 2008 02:56:22 PM UTC, comment #7: 

The designated initializer logic for NSWindow is in the initWithCoder: method of NSWindow.   Unfortunately, this means that the "defer" flag for NSWindows and NSWindow subclasses in gorm files will be ignored.   This shouldn't have a great impact, but it is not the correct behavior.

The change I've made corrects the immediate issue, but does not address the long term problem.  I will make a more permanent fix later today.

GC

Gregory John Casamento <gcasa>
Group administrator
Sat 24 May 2008 12:32:36 PM UTC, comment #6: 
Gregory John Casamento <gcasa>
Group administrator
Sat 24 May 2008 12:30:16 PM UTC, comment #5: 

As it turns out, this was caused by the fact that the initWithCoder method was calling

initWithContentRect:styleMask:defer:defer:screen:

Which is not the designated initializer for NSWindow.

This one is...
- (id)initWithContentRect:(NSRect)contentRect
styleMask:(unsigned int)styleMask
backing:(NSBackingStoreType)backingType
defer:(BOOL)flag

So I made it call that one and, now, it seems to work properly.

Thanks for reporting this... it was easier to fix than I thought it might be.  I'm going to do some additional testing prior to checking this in to make certain everything is working properly.  GC

Gregory John Casamento <gcasa>
Group administrator
Sat 24 May 2008 04:40:04 AM UTC, comment #4: 

Recreated.   I created a new gorm file for the gormtest application and reproduced this issue.

I am currently looking into a solution.   I believe the correct course of action is to make GSWindowTemplate in gorm loading more like it's nib counterpart which is NSWindowTemplate.

NSWindowTemplate holds all of the important attributes of the window and calls "initWithContentRect:styleMask:..." (the designated initializer) once in order to initialize the window.   This is the correct behavior.  

I will note any further discoveries here.  GJC

Gregory John Casamento <gcasa>
Group administrator
Fri 23 May 2008 08:59:31 PM UTC, comment #3: 

I'm still investigating this issue.

Gregory John Casamento <gcasa>
Group administrator
Fri 23 May 2008 08:58:37 PM UTC, comment #2: 

-------- Original-Nachricht --------

> On Thu, 22 May 2008, Gregory John Casamento wrote:
>
> > Given that Fabien said once he recreated the .gorm file it's not
> happening anymore and also that I can't make it happen in any other application, I
> believe we can consider this issue a non-issue.


Is this true Fabien? I am currently away from my computer and cannot test this, but from looking at the code in NSWindow, GSClassSwaper and GSWindowTemplate I would still expect that initWithContentRect:... gets called twice on the same NSWindow object. (BTW, shouldn't GSClassSwapper release self in initWithCoder:, when returning the new object?)
Greg, I understand it is hard to reproduce this without a proper example, but please try to look at the code and see what it does.


> > One note for the future, however.  I would really like everyone to
> start using the bug reporting system a little more.  This helps us tackle bugs
> and enhancement requests to meet your desires for GNUstep faster
> > since it is more easily tracked and is in one place as opposed to
> > emails, IMs, private messages on IRC, etc.
>
> My fault.
> I will try to use it :)


In this case it was also my fault. I should have put the remaining issue into our bug tracker, but it was so late at night, when I finally had your program more or less working. When I am back at my computer I will try to reproduce the problem with a tiny Gorm file and report it, if it still exists.

Fred

Gregory John Casamento <gcasa>
Group administrator
Fri 23 May 2008 08:57:55 PM UTC, comment #1: 

Follow ups..

I'm apparently missing something,... I get an error trying to compile that.

Gregory Casamento -- Principal Consultant - OLC, Inc
# GNUstep Chief Maintainer


----- Original Message ----
From: Fred Kiefer <fredkiefer@gmx.de>
To: Gregory John Casamento <greg_casamento@yahoo.com>
Cc: GNUstep Developer <gnustep-dev@gnu.org>
Sent: Tuesday, May 20, 2008 4:34:53 AM
Subject: Re: NSWindow & NSGraphicsContext issue

Strange, I get the log message as soon as I open an image from the
ToyViewer open menu entry.

The ToyViewer version I am using is this one:
http://www.sonappart.net/TV.tar.bz2

Hope this helps
Fred

Gregory John Casamento wrote:

> I've tried to recreate this issue.  I am not seeing the NSLog that was added come up once during my tests either when running the application (ToyViewer) or any other apps.
>
> I'm continuuing to look into it.  I'm going to open a bug on this so that the progress can be tracked there.
>
> GC
>
>  Gregory Casamento -- Principal Consultant - OLC, Inc
> # GNUstep Chief Maintainer
>
>
> ----- Original Message ----
> From: Gregory John Casamento <greg_casamento@yahoo.com>
> To: Fred Kiefer <fredkiefer@gmx.de>; GNUstep Developer <gnustep-dev@gnu.org>
> Sent: Monday, May 19, 2008 4:34:49 PM
> Subject: Re: NSWindow & NSGraphicsContext issue
>
> Fred,
>
> I will take a look at this as soon as possible.    The solution should allow existing gorm files to be handled properly as well as correct the problem going forward.
>
> GJC
>
> Gregory Casamento -- Principal Consultant - OLC, Inc
> # GNUstep Chief Maintainer
>
>
> ----- Original Message ----
> From: Fred Kiefer <fredkiefer@gmx.de>
> To: GNUstep Developer <gnustep-dev@gnu.org>
> Sent: Sunday, May 18, 2008 7:26:06 PM
> Subject: Re: NSWindow & NSGraphicsContext issue
>
> I was able to resolve most of the problems I listed below by not using
> autorelease objects.
>
> There still is one issue and it is an important one. When creating an
> NSWindow from a Gorm file the initialization is called twice. This will
> result in two backend objects being created for the window and one of
> them would leak and the window map would stay in an inconsistent state,
> after the window is freed. I was able to hack around this, by adding a
> check for an already existing _windowNum into
> initWithContentRect:styleMask:backing:defer:screen:. This only prevents
> part of the problem and a real fix would be not to have an NSWindow (or
> a subclass) in a Gorm file at all. For NIB files we already us
> NSWindowTemplate instead of GSWindowTemplate and this prevents the problem.
> Could somebody with a deeper understanding of Gorm please look into this
> issue?
>
> Fred
>
> Fred Kiefer wrote:
>> Last week I tried to resolve a circular refernce problem between
>> NSWindow and NSGraphicsContext.
>>
>> The source of the problem is that when an NSWindow gets displayed it
>> generates an NSGraphicsContext (or rather a subclass) which will then
>> manage all the actual drawing. The window retain the context and the
>> context has an info dictionary which includes the window. That way we
>> already start off with a circular reference. To break this I released
>> the window once, to adjust the retain count. Now when the window gets
>> deallocated I first do a retain on it and then release the graphics
>> context which will in turn result in a release on the window. Or so I
>> hoped. There were a few issues with my original code. The graphics
>> context and the dictionary where autorelease objects, so I had to
>> postpone the deallocation of the window by returning from dealloc and
>> let it be called again. This also needed a bit of isa sizzling as
>> subclasses will not be aware of that reference counting trick and wont
>> be prepared to get dealloc called twice. (And the code in NSWindow
>> dealloc needed to be reentrant as well)
>>
>> With that all resolved I expected my code now to work correctly, but
>> this still isn't the case. As it turns out, calling retain on an object
>> that already was about to get released wont have the expected result.
>> When a release is send to an object with a retain count of 1, that count
>> wont be changed! Now this means that I have to differentiate between
>> calls to _termianteWindow that come from dealloc, where I don't call the
>> retain and calls for oneShot windows, where I need to increase the
>> retain count before freeing the context.
>>
>> All of this now looks like an even bigger mess then the one I started
>> with and now any help on how to clearly solve this would be welcome.
>>
>> Cheers,
>> Fred
>>
>> PS: Some of the code I talk about above is still not committed.




_____________________________________________
Gnustep-dev mailing list
-email is unavailable-
http://lists.gnu.org/mailman/listinfo/gnustep-dev



    


_____________________________________________
Gnustep-dev mailing list
-email is unavailable-
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Gregory John Casamento <gcasa>
Group administrator
Fri 23 May 2008 08:57:27 PM UTC, original submission:  

Fabien tried noticed while testing ToyViewer that the initWithContentRect:... method was called twice when loading the .gorm file.


Gregory John Casamento <gcasa>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gcasa (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-05-24 gcasa StatusIn Progress Fixed
        Open/ClosedOpen In Test

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code