[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bugs #9536] NSDocument not including extention at time of delegate call
From: |
Fred Kiefer |
Subject: |
[bugs #9536] NSDocument not including extention at time of delegate call in save |
Date: |
Tue, 06 Jul 2004 17:25:40 -0400 |
User-agent: |
Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko) |
This mail is an automated notification from the bugs tracker
of the project: GNUstep.
/**************************************************************************/
[bugs #9536] Latest Modifications:
Changes by:
Fred Kiefer <FredKiefer@gmx.de>
'Date:
Tue 07/06/2004 at 21:22 (GMT)
------------------ Additional Follow-up Comments ----------------------------
Sorry, I am getting even more confused. In a private mail you wrote:
> Maybe it is due to multiple file types, but the issue is
> how is the title of a window handled: Should the file
> type be part of the window title, since the problem came
> from assuming that getTitle: would return the title of
> the file (I've since recoded so that I get the same
> result on both platforms, but it should be noted
> somewhere that Cocoa does give a different result than
> GNUstep: saved files have the extension in the title in
> Cocoa, they don't in GNUstep) probably not important
> unless you make the same foolish assumption I did.
This seems totally unrelated to the above problem of the
saveDocumentWithDelegate... method. (As unrelated as the PS you added, which
deals with the open panel). Yes all of this may be wrong behaviour from
GNUstep, but we need to sort them out first, than we are able to solve them.
Now the problem you describe in the mail seems to come from the way we
implement [NSWindowController synchronizeWindowTitleWithDocumentName] and this
looks very close to the Cocoa specification for the method. Perhaps Apple has
decided to use a different algorithm now. If you could provide detail for this,
we could rethink our implementation.
The other problem that you reported in the PS, should be reported separatly.
And please, could you provide example code plus instruction to reporduce the
problem in the future. This would save me the time of looking for the wrong
problem.
/**************************************************************************/
[bugs #9536] Full Item Snapshot:
URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=9536>
Project: GNUstep
Submitted by: 0
On: Fri 07/02/2004 at 21:29
Category: Gui/AppKit
Severity: 5 - Average
Item Group: Change Request
Resolution: None
Assigned to: None
Status: Open
Summary: NSDocument not including extention at time of delegate call in save
Original Submission: Using NSDocument -
(void)saveDocumentWithDelegate:(id)delegate
didSaveSelector:(SEL)didSaveSelector contextInfo:(void *)contextInfo and asking
for the file name does not yet include the extension. This means the app gets
the wrong name (= right name - extension) at that point. Extension is provided
in cocoa. I would argue that should be the same in GNUstep so the app has the
right, full name at time of save.
Follow-up Comments
------------------
-------------------------------------------------------
Date: Tue 07/06/2004 at 21:22 By: FredKiefer
Sorry, I am getting even more confused. In a private mail you wrote:
> Maybe it is due to multiple file types, but the issue is
> how is the title of a window handled: Should the file
> type be part of the window title, since the problem came
> from assuming that getTitle: would return the title of
> the file (I've since recoded so that I get the same
> result on both platforms, but it should be noted
> somewhere that Cocoa does give a different result than
> GNUstep: saved files have the extension in the title in
> Cocoa, they don't in GNUstep) probably not important
> unless you make the same foolish assumption I did.
This seems totally unrelated to the above problem of the
saveDocumentWithDelegate... method. (As unrelated as the PS you added, which
deals with the open panel). Yes all of this may be wrong behaviour from
GNUstep, but we need to sort them out first, than we are able to solve them.
Now the problem you describe in the mail seems to come from the way we
implement [NSWindowController synchronizeWindowTitleWithDocumentName] and this
looks very close to the Cocoa specification for the method. Perhaps Apple has
decided to use a different algorithm now. If you could provide detail for this,
we could rethink our implementation.
The other problem that you reported in the PS, should be reported separatly.
And please, could you provide example code plus instruction to reporduce the
problem in the future. This would save me the time of looking for the wrong
problem.
-------------------------------------------------------
Date: Tue 07/06/2004 at 17:20 By: FredKiefer
Did I understand this problem correctly: Inside of the didDaveSelector method
of the delegate you call (-fileName) on the NSDocument you get handed in and
the result is a filename without extension for GNUstep, whereas for Cocoa you
get a filename with extension?
I did not find any hint in this direction in our code, but there is aknow
difference to MacOSX 10.3. There you may set multiple allowed file types.
Perhaps your problem comes from this or something similar.
-------------------------------------------------------
Date: Sat 07/03/2004 at 01:11 By: allemandel3ft
P.S. This is when calling NSOpenPanel filenames/filename method. It should
return full paths (with extensions).
For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=9536>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/