Re: Problem with tabviews
Hi, Eric Wasylishen wrote: Thanks for the report! This one should be fixed now as well. It was a small code change but the explanation behind it is long; see ChangeLog for more detail. The cause was an earlier change I made for NSTabView to use flipped coordinates, and now the NSTabView subview frames in archives are incorrect. fine. this fixes also a Problem with the "Page layout" panel which I was about to report! I see now that the tabs in the page Panel do not fit. Did they never fit and our wiindow is just too small or the descriptions too long? Or did it work before? I don't remember... I'll test on an unupdated machine. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem with tabviews
Thanks for the report! This one should be fixed now as well. It was a small code change but the explanation behind it is long; see ChangeLog for more detail. The cause was an earlier change I made for NSTabView to use flipped coordinates, and now the NSTabView subview frames in archives are incorrect. Eric On 2013-10-14, at 10:59 PM, Germán Arias wrote: > El lun, 14-10-2013 a las 22:23 -0600, Eric Wasylishen escribió: >> Hi Germán, >> I think I see the problem, can you update gui and see if it's fixed for you? >> >> Looks like another case of stack corruption cause by: >> >> NSImage *img = ; >> NSSize s = [img size]; >> >> Eric >> > > Thanks, now works. But there is still other problem. See attached image, > that show the Gorm's inspector. > > Germán. > > > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem with tabviews
El lun, 14-10-2013 a las 22:23 -0600, Eric Wasylishen escribió: > Hi Germán, > I think I see the problem, can you update gui and see if it's fixed for you? > > Looks like another case of stack corruption cause by: > > NSImage *img = ; > NSSize s = [img size]; > > Eric > Thanks, now works. But there is still other problem. See attached image, that show the Gorm's inspector. Germán. <>___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem with tabviews
Hi Germán, I think I see the problem, can you update gui and see if it's fixed for you? Looks like another case of stack corruption cause by: NSImage *img = ; NSSize s = [img size]; Eric On 2013-10-14, at 9:38 PM, Germán Arias wrote: > With current SVN I can't launch FisicaLab or open the main gorm file. > This is the backtrace: > > Program received signal SIGSEGV, Segmentation fault. > 0x00846ffe in _OBJC_SELECTOR_TABLE () > from /usr/GNUstep/Local/Library/Libraries/libgnustep-gui.so.0.23 > (gdb) backtrace > #0 0x00846ffe in _OBJC_SELECTOR_TABLE () > from /usr/GNUstep/Local/Library/Libraries/libgnustep-gui.so.0.23 > #1 0x006af8e4 in -[GSTheme(Drawing) > drawTabViewRect:inView:withItems:selectedItem:] (self=0x831c330, > _cmd=0x7f2ca0, rect=..., view=0x83fbd20, >items=0x8649090, selected=0x86490c0) at GSThemeDrawing.m:2073 > #2 0x005d933d in -[NSTabView drawRect:] (self=0x83fbd20, _cmd=0x8179c0, >rect=...) at NSTabView.m:469 > #3 0x006403ae in -[NSView displayRectIgnoringOpacity:inContext:] ( >self=0x83fbd20, _cmd=0x8179b0, aRect=..., context=) >at NSView.m:2570 > #4 0x006405ce in -[NSView displayRectIgnoringOpacity:inContext:] ( >self=0x83fb630, _cmd=0x8179b0, aRect=..., context=) >at NSView.m:2604 > #5 0x006405ce in -[NSView displayRectIgnoringOpacity:inContext:] ( >self=0x83f9468, _cmd=0x8179b0, aRect=..., context=) >at NSView.m:2604 > #6 0x00631261 in -[NSView displayRectIgnoringOpacity:] (self=0x83f9468, >_cmd=0x8179a0, aRect=...) at NSView.m:2519 > #7 0x0063e301 in -[NSView displayIfNeededInRectIgnoringOpacity:] ( >self=0x83f9468, _cmd=0x817990, aRect=...) at NSView.m:2450 > #8 0x006310a3 in -[NSView displayIfNeededInRect:] (self=0x83f9468, >_cmd=0x817988, aRect=...) at NSView.m:2428 > #9 0x00630e82 in -[NSView displayIfNeeded] (self=0x83f9468, > _cmd=0x81e720) >at NSView.m:2410 > ---Type to continue, or q to quit--- > #10 0x0064a7a6 in -[NSWindow orderWindow:relativeTo:] (self=0x83f8a48, >_cmd=0x81e6d8, place=NSWindowAbove, otherWin=0) at NSWindow.m:1826 > #11 0x006459e9 in -[NSWindow orderFront:] (self=0x83f8a48, > _cmd=0x83c6d8, >sender=0x833a200) at NSWindow.m:1723 > #12 0x006969d1 in -[GSNibContainer awakeWithContext:] (self=0x833a200, >_cmd=0x854508, context=0x87fade8) at GSGormLoading.m:294 > #13 0x006cf047 in -[GSGormLoader > loadModelData:externalNameTable:withZone:] ( >self=0x81f49a0, _cmd=0x7c5110, data=0x81f2bc0, context=0x8360810, >zone=0xcdeb80) at GSGormLoader.m:120 > #14 0x00574d77 in -[NSNib instantiateNibWithExternalNameTable:withZone:] > ( >self=0x82c6bc8, _cmd=0x7792f0, externalNameTable=0x8360810, > zone=0xcdeb80) >at NSNib.m:153 > #15 0x004c5525 in +[NSBundle(NSBundleAdditions) > loadNibFile:externalNameTable:withZone:] (self=0xc77a00, _cmd=0x779378, > fileName=0x8227748, context=0x8360810, >zone=0xcdeb80) at NSBundleAdditions.m:235 > #16 0x004c5439 in -[NSBundle(NSBundleAdditions) > loadNibFile:externalNameTable:withZone:] (self=0x8212a08, _cmd=0x779318, > fileName=0x81f7650, >context=0x8360810, zone=0xcdeb80) at NSBundleAdditions.m:342 > #17 0x004c5704 in +[NSBundle(NSBundleAdditions) loadNibNamed:owner:] ( >self=0xc77a00, _cmd=0x7602f8, aNibName=0x81f7650, owner=0x8238678) >at NSBundleAdditions.m:277 > #18 0x004739cc in NSApplicationMain (argc=1, argv=0xbfffe374) at > Functions.m:83 > #19 0x08049f37 in main (argc=1, argv=0xbfffe374) at main.m:30 > > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem with tabViews in Renaissance
On 14.10.2012 07:33, Germán A. Arias wrote: Using Renaissance with gnustep update to svn, the tabviews don't work as expected. Just run the tabview examples to see the problem. I am able to reproduce this problem here and the reason seems to be a side effect of the changes Greg committed a few days ago. Now when adding the first item to a tab view this item gets selected by calling the proper method. Before that the code just set the selected item index, which is now gone (Or rather should be gone but isn't). If we remove this call things are back to normal. Calling that method results in the frame of the tab view item being set to the, still negative, content bounds of the tab view. This also happens on Apple and Nicola has a comment and a workaround for this in his Renaissance tab view code. But for some reason that workaround isn't sufficient for GNUstep. Looking more deeply into the Renaissance code I now understand that sizeToFitContent gets called for NSTabView at the end of the unarchiving. And the code there looks OK, still it results in wrong values for the subviews of the tab items. Most likely it's the negative size that we assign to some views in between that is causing the problem. But at the moment I don't see an easy way to resolve this. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
