[bug #34481] GNUstep seems to release top-level-nib objects although it shouldn't

URL: Summary: GNUstep seems to release top-level-nib objects although it shouldn't Project: GNUstep Submitted by: julian_ Submitted on: Mi 05 Okt 2011 12:57:34 GMT Category: Gui/AppKit

[bug #34481] GNUstep seems to release top-level-nib objects although it shouldn't

Follow-up Comment #1, bug #34481 (project gnustep): sending the top level xib objects an extra retain in awakeFromNib: "fixes" the issue, but this shouldn't be needed. ___ Reply to this item at: ___

[bug #34482] -[NSURLConnection sendSynchronousRequest:returningResponse:error:] doesn't set response

URL: Summary: -[NSURLConnection sendSynchronousRequest:returningResponse:error:] doesn't set response Project: GNUstep Submitted by: julian_ Submitted on: Mi 05 Okt 2011 13:26:23 GMT

[bug #34486] gnustep has a problem with non-ascii string constants

URL: Summary: gnustep has a problem with non-ascii string constants Project: GNUstep Submitted by: julian_ Submitted on: Mi 05 Okt 2011 17:41:30 GMT Category: Gui/AppKit

[bug #34487] gnustep doesn't load NSProgressIndicators from XIB files

URL: Summary: gnustep doesn't load NSProgressIndicators from XIB files Project: GNUstep Submitted by: julian_ Submitted on: Mi 05 Okt 2011 17:52:08 GMT Category: None S

[bug #34470] -[NSBitmapImageRep initWithFocusedViewRect:] broken

Follow-up Comment #3, bug #34470 (project gnustep): Eric, I understand that the right thing to do here would be to support graphic contexts based on bitmap data, which is not too hard to do for cairo. But for now wouldn't it resolve the problem to move the line drawing the current representation f

[bug #34488] gnustep wraps NSTextFields loaded from XIBs per-character even when it shouldn't

URL: Summary: gnustep wraps NSTextFields loaded from XIBs per-character even when it shouldn't Project: GNUstep Submitted by: julian_ Submitted on: Mi 05 Okt 2011 18:13:51 GMT Category

[bug #34470] -[NSBitmapImageRep initWithFocusedViewRect:] broken

Follow-up Comment #4, bug #34470 (project gnustep): Hi Fred, I think that would work, but it would take some work to test it. We really need a test for lockFocus/unlockFocus in GSTest or in the gui test suite. I was thinking of looking at this after the next release, maybe. There are other differ

[bug #34487] gnustep doesn't load NSProgressIndicators from XIB files

Follow-up Comment #1, bug #34487 (project gnustep): The NSprogressIndicators get loaded normally from the XIB file just as they should. The problem seems to be in the drawing code. As long as the progress indicators aren't started they don't get drawn. Looks like we need another flag here to get

[bug #34486] gnustep has a problem with non-ascii string constants

Follow-up Comment #1, bug #34486 (project gnustep): I think this is probably an application bug since historically non-ascii data in ObjC string constants has been disallowed (ie strings documented as having to be ascii and behavior for non-ascii documented as unsupported/undefined). Apple have al

[bug #34487] gnustep doesn't load NSProgressIndicators from XIB files

Follow-up Comment #2, bug #34487 (project gnustep): >As long as the progress indicators aren't started they don't get drawn. oh ok. i therefore guess sending them start and stop should work around the issue. thanks for the workaround. >Looks like we need another flag here to get the drawing cod

[bug #34486] gnustep has a problem with non-ascii string constants

Follow-up Comment #2, bug #34486 (project gnustep): >historically non-ascii data in ObjC string constants has been disallowed yes, historically, but this has been changed with Mac OS X 10.5 and i think GNUstep should follow here. source files are encouraged to be UTF-8 and objc string constants w

[bug #34487] gnustep doesn't load NSProgressIndicators from XIB files

Follow-up Comment #3, bug #34487 (project gnustep): workaround doesn't seem to work - just sending [progressIndicator startAnimation:self]; [progressIndicator stopAnimation:self]; doesn't seem to get 'em drawing ___ Reply to this item at

[bug #34486] gnustep has a problem with non-ascii string constants

Follow-up Comment #3, bug #34486 (project gnustep): Pretty much the two workarounds right now are putting the utf-16 codepoints in an array and then using -initWithCharacters:length:, or else loading the string from a file (maybe using NSLocalizedString?) unichar string[2] = { 0x0068, 0x00e }; //

[bug #34486] gnustep has a problem with non-ascii string constants

Update of bug #34486 (project gnustep): Category: Gui/AppKit => Base/Foundation Severity: 3 - Normal => 1 - Wish Status:None => Confirmed _

[bug #34486] gnustep has a problem with non-ascii string constants

Follow-up Comment #4, bug #34486 (project gnustep): ugh if there is no way at all to get it into a string *constant* it really is a pain. i've currently this code and see no way how i'd be able to convert that #define kTrackNames[NSArray arrayWithObjects:@"Tannhäuser Stargate", @"Soyl

[bug #34486] gnustep has a problem with non-ascii string constants

Follow-up Comment #5, bug #34486 (project gnustep): Oh, you can do this: (UTF8 macro just for clarity) #define UTF8(x) [NSString stringWithUTF8String: x] #define kTrackNames [NSArray arrayWithObjects: UTF8("Tannhäuser Stargate"), UTF8("Soylent Black"), UTF8("Quantum Circuit"), UTF8("Blaspheme Qua

[bug #34486] gnustep has a problem with non-ascii string constants

Follow-up Comment #6, bug #34486 (project gnustep): i can confirm that works fine. thanks for another nice workaround. ___ Reply to this item at: ___ Na

[bug #34490] -[NSWorkspace open*] implemented uselessly

URL: Summary: -[NSWorkspace open*] implemented uselessly Project: GNUstep Submitted by: julian_ Submitted on: Mi 05 Okt 2011 21:59:03 GMT Category: Gui/AppKit Severity:

[bug #34490] -[NSWorkspace open*] implemented uselessly

Follow-up Comment #1, bug #34490 (project gnustep): First ... 'if they don't find a GNUSTEP application to open the file / url, they just fail - even if non-GNUSTEP apps to open the file/url are installed' is not accurate ... in fact they can open any app whether gnustep or not ... you just have t

[bug #34490] -[NSWorkspace open*] native system integration

Update of bug #34490 (project gnustep): Item Group:None => Change Request Summary: -[NSWorkspace open*] implemented uselessly => -[NSWorkspace open*] native system integration ___

[bug #34490] -[NSWorkspace open*] native system integration

Follow-up Comment #3, bug #34490 (project gnustep): >GWorkspace i don't think these APIs should depend on GWorkspace (i don't have it) and the idea of having to wrap any linux app in existence ... sounds not so bright. >a. not work on any system without xdg-open AFAIK all linux distributions

[bug #34490] -[NSWorkspace open*] native system integration

Follow-up Comment #4, bug #34490 (project gnustep): new patch with experimental native code path for win32 which uses ShellExecuteW(). can't verify the win32 path, may also need an include of (file #24109) ___ Additional Item Attachment:

[bug #34490] -[NSWorkspace open*] native system integration

Follow-up Comment #5, bug #34490 (project gnustep): the new patch may not apply cleanly since i don't have access to the linux machine ATM i just added the new lines to the old patch. i think you will be able to sort it out. ___ Reply to th

[bug #34490] -[NSWorkspace open*] native system integration

Follow-up Comment #6, bug #34490 (project gnustep): now without memleak (file #24110) ___ Additional Item Attachment: File name: open_exp2.diff Size:1 KB ___ Reply