Re: Theme problem with first responder
Hi Germán, This is probably caused by a change I made last fall to allow theming the first responder state. See https://github.com/gnustep/gnustep-gui/blob/master/Source/GSTheme.m#L1120 . And for an example theme http://svn.gna.org/svn/etoile/trunk/Etoile/Themes/Nesedah.theme/ Perhaps that method in gstheme should do a fall back if the theme doesn't provide first responder tiles. As a workaround just make another button tile with the suffix FirsrResponder. Eric On Mar 18, 2014 5:34 PM, Germán Arias germanan...@gmx.es wrote: This problem occurs when the theme show tiles at buttons. When a button is the first responder this lose its tile. See attached image. When the button isn't the first responder, this again shows the tile. themeProblem.jpg Germán. ___ 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: memory leak - cairo/x11 backend
Hi Riccardo, +Fred +gnustep-dev
On Dec 18, 2013, at 7:40 AM, Riccardo Mottola riccardo.mott...@libero.it
wrote:
Hi,
Eric Wasylishen wrote:
Hi Riccardo,
As a starting point for debugging I would put NSLog's in
XGCairoModernSurface -initWithDevice: and -dealloc. This is where we retain
/ release the Cairo surface that is holding memory in the x server.
Also I would put logging in -NSImage set name:, log [nameDict allKeys] to
see which images are kept in memory by nameDict.
I did so, in setName.. It does not get called from laternaMagica when
switching images. WHile the application loads and shows its windows I see
stuff like:
2013-12-18 15:36:39.356 LaternaMagica[18906] NSimage setName, keys:
(common_ret H, common_Nibble, common_HomeDirectory, NSApplicationIcon,
common_UnknownT ool, GSMenuArrow, common_Mount, common_DownloadFolder,
common_ArrowDown, laternamagica_48.tif, common_Home,
common_ArrowLeftH, common_Close, com mon_3DArrowLeft, common_Desktop,
common_ImageFolder, GSMenuSelected, commo n_3DArrowRightH, GSSwitch,
GSSwitchSelected, common_GSFolder, common_Dimple , common_Unmount,
common_DimpleHoriz, common_ArrowRightH, common_DocsFold er,
common_Unknown, common_ArrowUpH, GSMenuMixed, NSFolder, common_ArrowUp
, common_3DArrowUp, common_ArrowRight, common_3DArrowDown,
common_ArrowD ownH, common_ret, common_ArrowLeft, common_SliderHoriz)
however when I load images from disk and cycle between them, nothing gets
printed, meaning that setName doesn't get called.
Riccardo
Actually, I was on the wrong track; I just found the problem.
During the creation of a window, we run -[XGServerWindow
setWindowdevice:forContext:]. The problem is, inside that method we call [self
_createBuffer] which does window-buffer = XCreatePixmap(…), but the [self
_createBuffer] call is *before* window-gdriverProtocol is initialized.
window-gdriverProtocol is set from the -init… method of XGCairoModernSurface.
The call sequence that causes the leak looks like:
-[XGServerWindow setWindowdevice:forContext:]
-[XGServerWindow _createBuffer]
(performs window-buffer = XCreatePixmap because window-gdriverProtocol == 0)
GSSetDevice()
-[XGCairoModernSurface initWIthDevice:]
(sets window-gdriverProtocol to GDriverHandlesExpose | GDriverHandlesBacking)
…later….
-[XGServerWindow termwindow] doesn’t free window-buffer because
window-gdriverProtocol has the GDriverHandlesBacking bit set.
As a quick fix, I reordered this section of -[XGServerWindow
setWindowdevice:forContext:]
if (window-buffer == 0)
{
[self _createBuffer: window];
}
[self styleoffsets: l : r : t : b
: window-win_attrs.window_style : window-ident];
GSSetDevice(ctxt, window, l, NSHeight(window-xframe) + b);
to:
[self styleoffsets: l : r : t : b
: window-win_attrs.window_style : window-ident];
GSSetDevice(ctxt, window, l, NSHeight(window-xframe) + b);
if (window-buffer == 0)
{
[self _createBuffer: window];
}
which fixed the leak, however it causes apps to segfault with the xlib backend.
Probably some code in -styleoffsets or GSSetDevice attempts to use
window-buffer.
I just committed a more foolproof fix, which is just disabling all of the code
in -_createBuffer if we are building with the cairo backend. As I noted in the
comment there, I don’t like the window-gdriverProtocol abstraction as it’s
trying to handle different library configurations in “too dynamic” of a way.
Testing is welcome; the leak is gone for me and LaternaMagica seems a lot
faster too.
Cheers,
Eric
PS, ignore my comments about caching, for some reason I was thinking that all
NSImages would go in namedict. What we have now is more or less fine, UI
resources loaded with +imageNamed: are kept cached in nameDict and others are
not.
___
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 germanan...@gmx.es 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 = something that returns nil; 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. tabviews.png ___ 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 = something that returns nil; NSSize s = [img size]; Eric On 2013-10-14, at 9:38 PM, Germán Arias germanan...@gmx.es 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=optimized out) at NSView.m:2570 #4 0x006405ce in -[NSView displayRectIgnoringOpacity:inContext:] ( self=0x83fb630, _cmd=0x8179b0, aRect=..., context=optimized out) at NSView.m:2604 #5 0x006405ce in -[NSView displayRectIgnoringOpacity:inContext:] ( self=0x83f9468, _cmd=0x8179b0, aRect=..., context=optimized out) 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 return to continue, or q return 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
themes: highlighted cell text colors
Hi, I'm working on the Nesedah theme: http://jesseross.com/clients/gnustep/ui/concepts/23/camaelon_nesedah.png One thing that is giving me trouble is getting selected cells in NSTableView and NSBrowser to have a highlighted text color. For tables, I've found the relevant place in GSThemeDrawing.m; it's -drawTableViewRow:clipRect:inView:, and I have access to the NSCell and know whether the table cell should be selected. My problem is, I don't know how I should I set up the cell. Simply calling -setHighlighted: YES doesn't cause a NSTextFieldCell to draw differently than normal. I could explicitly set the text color to a highlighted text color in -drawTableViewRow:clipRect:inView:, but this would break cells that have custom text colors already set, which seems like a bad thing. I'd appreciate any hints! Thanks, Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problems debugging with clang 3.2, gdb 7.6, libobjc2 SVN, and Ubuntu 13.10
Thanks for the pointers… I reconfigured make without enabling the nonfragile ABI (just used CC=clang ./configure --enable-debug-by-default), rebuilt everything, and now stepping into Objective-C methods works with gdb, as does ivar printing. So do gdb and lldb need some changes to support the nonfragile ABI? If that's the case, maybe we should display a warning when configuring make with --enable-nonfragile-abi, so people know that debugging will be broken. Eric On 2013-10-04, at 4:43 PM, Ivan Vučica ivuc...@gmail.com wrote: On 4. 10. 2013., at 21:50, Eric Wasylishen ewasylis...@gmail.com wrote: 2. Printing ivars is broken. gdb seems to print self-isa when you do print someivar or print self-someivar. lldb-3.2 prints an error asking you to report a bug. I configured gnustep-make with --enable-debug-by-default --enable-objc-nonfragile-abi, gnustep-base with --disable-mixedabi. I talked to Alex S. on Étoilé IRC and he observed the same two problems on a similar setup as me; Quentin also mentioned the ivar printing problem to me. I've also had similar problem with printing Objective-C variables on Ubuntu 12.04, and whatever-gdb-ships-with-12-04. I think my install has a post-3.2 clang SVN, possibly post-3.3. I would suspect it's an incompatibility between libobjc2 and gdb/lldb, though it would be strange if David didn't see it. -- Ivan Vučica i...@vucica.net - http://ivan.vucica.net/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
problems debugging with clang 3.2, gdb 7.6, libobjc2 SVN, and Ubuntu 13.10
Hi, Just want to report that I got a new development environment set up, and I've observed two problems with debuggers: 1. step / s command in gdb doesn't step in to Objective-C methods; it acts like next/n and steps to the next line of code. I've verified that I'm compiling code with 'make debug=yes'. Same thing happens with gdb 7.6 or lldb-3.3. 2. Printing ivars is broken. gdb seems to print self-isa when you do print someivar or print self-someivar. lldb-3.2 prints an error asking you to report a bug. I configured gnustep-make with --enable-debug-by-default --enable-objc-nonfragile-abi, gnustep-base with --disable-mixedabi. I talked to Alex S. on Étoilé IRC and he observed the same two problems on a similar setup as me; Quentin also mentioned the ivar printing problem to me. Anyone have an idea of where the actual problem lies, and possible workarounds? I have yet to try newer versions of clang, and plan to do that. Thanks, Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Opal patch
Hi Philippe,
Sorry for taking so long - I just applied your patches, they look good.
Thanks,
Eric
On 2013-09-27, at 10:59 AM, Philippe Roussel p.o.rous...@free.fr wrote:
Hi Ivan,
You seem to be working on opal, could you take a look at the following ?
Philippe
On Thu, Sep 19, 2013 at 07:21:40AM +0200, Philippe Roussel wrote:
Hi,
Scanning opal build warnings I found at least 2 that look like real
bugs, see the following patch.
Philippe
Index: Source/OpalGraphics/CGImage.m
===
--- Source/OpalGraphics/CGImage.m(révision 37110)
+++ Source/OpalGraphics/CGImage.m(copie de travail)
@@ -158,7 +158,7 @@
self-surf = NULL;
self-bitmapInfo = aBitmapInfo;
self-cspace = CGColorSpaceRetain(aColorspace);
- self-intent = intent;
+ self-intent = anIntent;
return self;
}
Index: Source/OpalText/CTLine.m
===
--- Source/OpalText/CTLine.m (révision 37110)
+++ Source/OpalText/CTLine.m (copie de travail)
@@ -30,7 +30,7 @@
- (id)initWithRuns: (NSArray*)runs
{
- if ((self == [super init]))
+ if ((self = [super init]))
{
_runs = [runs retain];
}
--
Letting the Internet be rewired by bureaucrats would be like handing a
Stradivarius to a gorilla. L. Gordon Crovitz
___
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: Wrong order when process some events
Hi Fred, I found one I can consistently reproduce with the current gui: Open the memory panel (e.g. in Ink, open app info, click on app icon). Click on the memory window to focus it. Position the mouse over one of the table header dividers to get the horizontal resize cursor. Then, scroll very quickly for a second or two (the more scroll events you generate the more reliably this will work). When you move the mouse away the horizontal resize cursor should stick. Your explanation makes sense to me, I'm not sure why the hack is breaking. Eric On 2013-08-28, at 1:09 PM, Germán Arias ger...@xelalug.org wrote: For the moment, the one problem that I can reproduce is this: On 2013-08-28 01:12:38 -0600 Fred Kiefer fredkie...@gmx.de wrote: On 2013-08-27 22:35:49 -0600 Germán Arias ger...@xelalug.org wrote: After more tests, I found problems with your hack. Open Ink and then select Colors panel at menu and move the mouse (fast) over the textview, this will stuck the cursor as an I-beam. Germán. Other problems are random. Or at least I can't reproduce these easily. Germán. ___ 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
back/x11 XIM fix [was: Re: Gworkspace with non-fragile abi, etc?]
Hi, Thanks for the feedback. I'll just address this one question: 3) XIM at X11 backends To input non-latin character at text box of gnustep applicaton, I tried all XIM such as ibus, scim, uim, fcitx, but failed. After then, this document was found: Input ( http://wiki.gnustep.org/index.php/I18n ) NSTextInput protocol NSInputManager Current Status Currently we use XIM. It is only available on systems that use the X11 backends. Default backend at linux seems to be cairo. Does not cairo backend support XIM? When backend was changed into xlib, applications were not excuted as failed to load true-type fonts. Because direct keyboard input is not allowed, indirect and incomplete copy-paste input is only available. Yes, XIM should work with cairo (or any of the graphics backends, as long as the window server backend is x11). However, it looks like I broke XIM support over a year ago. :-( I just committed a fix for now: * Source/x11/XIMInputServer.m: Add the setlocale(LC_CTYPE, ) call back that I removed last year (r35152). I tested the fcitx input method, and without the setlocale call, XOpenIM would fail. I'm not sure what the best plan is in the long term, I wanted to avoid calling setlocale from the core frameworks but in this case xlib seems to require it. To test gnustep with fcitx, I ran: export XMODIFIERS=@im=fcitx in my shell before launching Ink, and then was able to press ctrl+space to enter Chinese characters. Could you try doing an svn update on core/back and see if the fix works for you? Cheers, Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Size of NSInteger/NSUInteger/CFIndex
Hey Stef, I think what GNUstep is doing is OK... On 2013-08-20, at 3:34 PM, Stefan Bidi stefanb...@gmail.com wrote: I'm re-writing the CoreBase string formatting function (printf with %@ support) and while going through the printf(), Apple docs and other sources on the internet I ran across a potential problem with some of the assumptions made when defining these types. I understand that despite being very portable, GNUstep isn't made to work on all platforms, but I'm still going to use an unlikely platform as example... Anyway, in the Apple docs, they have: typedef long NSInteger; typedef unsigned long NSUInteger typedef long CFIndex; Yet, the discussion says: When building 32-bit applications, NSInteger is a 32-bit integer. A 64-bit application treats NSInteger as a 64-bit integer. This is true on LP64 platforms but not on any other platform. It's tricky, because we don't have a definitive specification. I don't think the typedef long NSInteger mentioned in the docs is the final/proper definition of NSInteger. For example, on OS X 10.8, NSInteger can be defined as 'int' under some circumstances. The problem that I see here is that the Apple docs about string formatting say that if you want to format a NSInteger/NSUInteger/CFIndex you should use '%ld' or '%lu'. This is from a table in String Programming Guide, right? I think you may have missed the Considerations column which says to cast the value to a long when using the %ld format specifier. This seems to be the accepted interpretation on stackoverflow as well: http://stackoverflow.com/questions/4405006/nslog-specifier-for-nsinteger GNUstep, on the other hand, defines these values as intptr_t/uintptr_t, which in my opinion is wrong. We essentially assume these types are as long as a pointer, which is true if you assume LP64. However, this assumption is not true for a cross-platform library. Lastly, I was browsing the web and came across this (http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html) where int is 16-bits, long is 32-bits and intptr_t is 16-bits. I realize AVR is not a target, but I just wanted to use it as another example where long is not equivalent to intptr_t. And who known, someone might want to use it in the future. I would like to suggest typedef'ing NSInteger/NSUInteger/CFIndex as long. That way we can correctly format these integers across all platforms supported by GNUstep. Hope my point addresses your concern. Cheers, Eric___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NIB loader: custom views don't draw themselves
Hi Luboš, The green view shows up for me. I'm on the latest gui from svn (36950), and just downloaded the example and built with pbxbuild. I also tested with the Narcissus theme like you're using and it still worked. Are you also on the latest revision? I can reproduce the text becoming right-aligned when clicking on the text field, I'll have a look. Eric On 2013-08-06, at 2:32 PM, Luboš Doležel lu...@dolezel.info wrote: Hi, I come again ask for help with the NIB loader. I've taken the example app from [1], recompiled it for 64-bits and started it up under Darling/GNUstep. It should look like [2], but it actually looks like what you can find attached. The app includes a very simple NSView subclass called MyCustomView. An instance of this class is properly created, because the two buttons successfully invoke methods of MyCustomView (checked that). I've added some debug statements and quickly learned why there is no green rectangle: Method -drawRect: of MyCustomView is never called. Any idea why? I think I've seen similar issues in other apps too. Also, the centered text field becomes right aligned after I click on it. It doesn't exhibit such behavior under OS X and it doesn't make sense. Luboš [1] http://juliuspaintings.co.uk/cgi-bin/paint_css/animatedPaint/018-NSButton-NSView.pl [2] http://juliuspaintings.co.uk/pictureData/animatedPaint/018-3-Run-IBOutlet-NSView.jpg nsview.png___ 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: NSOrderedSet implementation
Hi Luboš, I started implementing NSOrderedSet but got distracted with some other things. My current idea is to use a combination of an NSMutableArray, and a NSMapTable configured to map objects to integers. The idea is that the array maps the object's index to the object, and the map table maps objects to their index. I have some untested code that illustrates the idea here: http://svn.gna.org/svn/etoile/trunk/Etoile/Frameworks/CoreObject/Sandbox/COWeakMutableOrderedSet.m This is just a NSMutableOrderedSet subclass where I wanted weak references, but I think we could use the same code for a concrete GSMutableOrderedSet subclass. Btw, those are all of the primitive methods for NSOrderedSet / NSMutableOrderedSet according to the Foundation release notes. Eric On 2013-07-23, at 3:45 AM, Luboš Doležel lu...@dolezel.info wrote: Hi, gnustep-base currently lacks NSOrderedSet. Before I set to work, does gnustep-base include any primitives that could be/should be used for this? This seems to be a case for a binary tree. -- Luboš Doležel ___ 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: Still getting the following failure...
Hi Greg, Looks like InitialisePathUtilities is catching and re-throwing an exception on line 1180. Could you break on objc_exception_throw and re-run to see if you can get a stack trace from the initial exception? We know it'll be an -initWithBytes:lenth:encoding given nul bytes exception, but I don't know where in the NS_DURING block of InitialisePathUtilities that the failing -initWithBytes call is being made. Eric On 2013-07-20, at 10:59 AM, Gregory Casamento greg.casame...@gmail.com wrote: Backtrace for failure in pl2link Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. /usr/GNUstep/System/Tools/pl2link: Uncaught exception (null), reason: -initWithBytes:lenth:encoding given nul bytes Program received signal SIGABRT, Aborted. 0x73712475 in raise () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x73712475 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x737156f0 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x775b2754 in _terminate () at NSException.m:754 #3 0x775b2717 in _NSFoundationUncaughtExceptionHandler (exception=0x7ffea0) at NSException.m:778 #4 0x775b0e89 in callUncaughtHandler (value=0x7ffea0) at NSException.m:798 #5 0x7700fbb9 in objc_exception_throw () from /usr/GNUstep/Local/Library/Libraries/libobjc.so.4 #6 0x775b1e7f in -[NSException raise] (self=0x7ffea0, _cmd=0x77b38f60) at NSException.m:970 #7 0x7762881d in InitialisePathUtilities () at NSPathUtilities.m:1180 #8 0x7762918d in NSSearchPathForDirectoriesInDomains (directoryKey=1, domainMask=2, expandTilde=1 '\001') at NSPathUtilities.m:2080 #9 0x00402530 in main (argc=2, argv=0x7fffe188, env=0x7fffe1a0) at pl2link.m:160 (gdb) up #1 0x737156f0 in abort () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) #2 0x775b2754 in _terminate () at NSException.m:754 754 abort(); (gdb) #3 0x775b2717 in _NSFoundationUncaughtExceptionHandler (exception=0x7ffea0) at NSException.m:778 778 _terminate(); (gdb) #4 0x775b0e89 in callUncaughtHandler (value=0x7ffea0) at NSException.m:798 798 _NSFoundationUncaughtExceptionHandler(value); (gdb) #5 0x7700fbb9 in objc_exception_throw () from /usr/GNUstep/Local/Library/Libraries/libobjc.so.4 (gdb) #6 0x775b1e7f in -[NSException raise] (self=0x7ffea0, _cmd=0x77b38f60) at NSException.m:970 970 @throw self; (gdb) #7 0x7762881d in InitialisePathUtilities () at NSPathUtilities.m:1180 1180[localException raise]; (gdb) #8 0x7762918d in NSSearchPathForDirectoriesInDomains (directoryKey=1, domainMask=2, expandTilde=1 '\001') at NSPathUtilities.m:2080 2080InitialisePathUtilities(); (gdb) #9 0x00402530 in main (argc=2, argv=0x7fffe188, env=0x7fffe1a0) at pl2link.m:160 160 installPaths = NSSearchPathForDirectoriesInDomains (NSApplicationDirectory, domain, YES); (gdb) On Fri, Jul 19, 2013 at 7:12 PM, Riccardo Mottola riccardo.mott...@libero.it wrote: Hi, Richard Frith-Macdonald wrote: Creating Gorm.app/Resources/Info-gnustep.plist... plmerge: Uncaught exception (null), reason: -initWithBytes:lenth:encoding given nul bytes I have reported it in a previous message but nobody cares ... See my second message entitled : compiling GNUstep with clang, in my first message I wrote that I had some errors than I have understood I needed to compile libc++ then in my second message I had a crash inside plmerge : I am copy/pasting : if [ -r libgnustep-back-023Info.plist ]; then \ plmerge libgnustep-back-023.bundle/Resources/Info-gnustep.plist libgnustep-back-023Info.plist; \ fi plmerge: Uncaught exception (null), reason: -initWithBytes:lenth:encoding given nul bytes Aborted make[3]: *** [libgnustep-back-023.bundle/Resources/Info-gnustep.plist] Error 134 make[3]: *** Deleting file `libgnustep-back-023.bundle/Resources/Info-gnustep.plist' make[2]: *** [libgnustep-back-023.all.bundle.variables] Error 2 make[1]: *** [internal-all] Error 2 make[1]: Leaving directory `/home/vincent/objc2cs/gnustep/core/back/Source' This problem appeared some days ago because of a commit of Richard, which he readily reverted. Giving up is surely not a solution, I run GNUstep on really a wide range of platforms! If you don't need certain features, you may try gcc (however, reconfigure and recompile all core with gcc). any gcc 4.x will do just fine. I can assure that a 4.2 is rock stable. Perhaps you should do that anyway, just to exclude other troubles? Perhaps nobody is responding because it's not a problem anybody has seen (I haven't). I'm not a regular user of clang myself because I mostly want reliability and clang has been highly unstable,
Re: GNUstep don't load images of current theme.
Hi Greg, There were several things we tried to do: - make a clearly defined set of image names (listed in Headers/Additions/GNUstepGUI/GSTheme.h ) for themes to override. Currently we just have GSSwitch and GSRadio listed there. - make the image names for themes to override describe what the image is used for (GSMenuArrow rather than common_3DArrowRight) - use a standard formula for choosing the names of alternate image state (e.g. GSRadio, GSRadioSelected, GSRadioDisabled, GSRadioDisabledSelected). The change that breaks existing themes is that the images now have to be listed in the theme's plist in a GSThemeImages dictionary. Perhaps requiring this is not the way to go. Themes now use the mapping file, btw. :) +[imageNamed: aName] always looks up aName in the mapping file, and uses the mapped name to call +[NSImage _pathForImageNamed:] and stores the resulting image in the nameDict under the mapped name.The intention is that if a mapping exists in nsmapping.strings, the image will always be stored in nameDict under the mapped name. Eric P.S., Quentin, it seems the Aristo2.theme's theme info plist is not committed in etoile svn. Could you commit that so we have a minimal example of the new theme format? On 2013-07-16, at 6:11 PM, Gregory Casamento greg.casame...@gmail.com wrote: Eric, The theme image replacement code was buggy, but it worked better than nothing. So, what you're saying is, we now have nothing. I'm not sure I see how this improves the situation. Is it possible to put some code in to replace this which will perform a similar function? Also, the issue what you were seeing where it needed to have several names was, likely, due to the fact that themes do not read the mappings file. GC On Tue, Jul 16, 2013 at 4:12 AM, Riccardo Mottola riccardo.mott...@libero.it wrote: Hi, just as reference, these are the images currently part of the Sleek theme of CVS, which is the most comprehensive theme at the moment: $ ls -p Sleek.theme/Resources/ThemeImages/ CVS/ common_3DArrowRight.tiff common_Desktop.tif common_Dimple.tif common_DimpleHoriz.tif common_DocsFolder.tif common_DownloadFolder.tif common_Folder.tif common_GSFolder.tif common_Home.tif common_HomeDirectory.tif common_ImageFolder.tif common_LibraryFolder.tif common_Mount.tif common_MusicFolder.tif common_Nibble.tif common_RadioOff.tif common_RadioOn.tif common_Right.tif common_Root_PC.tif common_SwitchOff.tif common_SwitchOn.tif common_ToolbarCustomizeToolbarItem.tiff common_Unknown.tif common_UnknownApplication.tiff common_UnknownTool.tif common_Unmount.tif common_outlineCollapsed.tif common_outlineExpanded.tiff common_outlineUnexpandable.tiff common_ret.tiff common_retH.tiff outlineCollapsed.tiff The only one that looks out of place is outlineCollapsed which is present twice. The theme is created and maintained in Thematic. The fact that they are named common_ * has already been matter of discussion and I lost :) Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev -- Gregory Casamento Open Logic Corporation, Principal Consultant yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) http://www.gnustep.org http://heronsperch.blogspot.com ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep don't load images of current theme.
Hey Riccardo, Quentin reworked gui's code for handling theme images during the hackathon, to make the process for creating new themes saner. (we fixed the problem where themes had to provide each image under several names, e.g. common_SwitchOff and and NSSwitchOff) This may have broken existing themes, though. Iirc we didn't yet properly announce the changes on the mailing list because there were a few other things we wanted to clean up (e.g. adding support for specifying colors in HTML notation). I helped a bit too so I can probably take a look at neos and see what needs to be updated. Eric On Jul 15, 2013 12:43 PM, Riccardo Mottola riccardo.mott...@libero.it wrote: Hi, Germán Arias wrote: GNUstep don't use the images of current theme. For example, if set Neos theme I don't see the images of this theme. I noticed the same too.. I wanted to udpate certain details in Neos.. and just checking the existing, wroking version I notice that the UI elements get themed, but all the folder icons and stuff used by GWorkspace get ignored. Riccardo __**_ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/**listinfo/gnustep-devhttps://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: MAC_OS_X_VERSION macros
Hi Frank, Thanks for bringing this up - it's indeed a nasty problem (although hopefully pretty easy to fix :) A year or two ago I was working on updating macports patches for building GNUstep on OS X 10.6/10.7, and ran in to an instance of this here: https://github.com/ericwa/gnustep-macports-fixes/blob/master/gnustep/gnustep-back/files/patch-CairoFaceInfo.h I forget the details but I think I was working around GNUstep pulling in OS X's MAC_OS_X_VERSION_MAX_ALLOWED. My take on it is, we (GNUstep) should avoid using symbols that Apple is shipping in their availability macros, since the availability macros on OS X are included in standard C headers (e.g. /usr/include/stdlib.h). I'd propose modifying this section of base/Headers/GNUstepBase/GSVersionMacros.h: /* * For MacOS-X compatibility, we define the MacOS-X version constants and * we allow MAC_OS_X_VERSION_MIN_ALLOWED or MAC_OS_X_VERSION_MAX_ALLOWED * instead of GS_OPENSTEP_V */ #ifndef MAC_OS_X_VERSION_10_0 #define MAC_OS_X_VERSION_10_0 10 #define MAC_OS_X_VERSION_10_1 100100 #define MAC_OS_X_VERSION_10_2 100200 #define MAC_OS_X_VERSION_10_3 100300 #define MAC_OS_X_VERSION_10_4 100400 #define MAC_OS_X_VERSION_10_5 100500 #define MAC_OS_X_VERSION_10_6 100600 #endif /* MAC_OS_X_VERSION_10_0 */ #ifndef GS_OPENSTEP_V #ifdef MAC_OS_X_VERSION_MIN_ALLOWED #define GS_OPENSTEP_V MAC_OS_X_VERSION_MIN_ALLOWED #else #ifdef MAC_OS_X_VERSION_MAX_ALLOWED #define GS_OPENSTEP_V MAC_OS_X_VERSION_MAX_ALLOWED #endif /* MAC_OS_X_VERSION_MAX_ALLOWED */ #endif /* MAC_OS_X_VERSION_MIN_ALLOWED */ #endif /* GS_OPENSTEP_V */ We could rename the MAC_OS_X_VERSION_* to GS_OS_X_VERSION_*, and eliminate the section below that makes MAC_OS_X_VERSION_MIN_ALLOWED or MAC_OS_X_VERSION_MAX_ALLOWED an alias for GS_OPENSTEP_V. Maybe someone who has more background on the history of these macros in GS can chime in? Eric On 2013-06-03, at 6:06 PM, Frank Rehwinkel frankrehwin...@gmail.com wrote: I think the build is currently broken on OS X 10.8 and I think there are typos so I was just asking for experienced advice what path to take to fix it. I guess it's also possible it is not broken for other people on their 10.8 systems but if that's the case, I'd like to hear about it. Thanks, -Frank On Mon, Jun 3, 2013 at 6:00 PM, Maxthon Chan xcvi...@me.com wrote: Don't panic, as Apple will switch back in no more than 2 years - when they reached OS X 10.10 (OS X 10.9 is pretty much confirmed in this year's WWDC - I am a paid iOS developer so I have access to these Apple Prerelease information. Or maybe at that time there will be no more OS X, and the new OS is called iOS 11 all across desktop and mobile devices). 在 2013-6-4，上午5:55，Frank Rehwinkel frankrehwin...@gmail.com 写道： I'm confused by GNUstep's use of the MAC_OS_X_VERSION macros which are similar but not identical to Apple's and by what appear to be typos in some of their use. The system headers in my OS X 10.8 system define four digit version numbers but GNUstep is built on six digit version numbers. Also Apple's documentation gives an example of using a four digit number, 1050, to represent the 10.5 version of OS X. http://developer.apple.com/library/ios/#documentation/DeveloperTools/Conceptual/cross_development/Using/using.html#//apple_ref/doc/uid/20002000-SW6 Was Apple's version number once six digits or was it always four and GNUstep needed/wanted to use six? At the moment, the test for OS X version is broken because the four digit value is being picked up from the system header (1080) and it works out to be less than an old version number because fewer digits are being used (100500 in the first case I tracked down). The simplest fix would seem to be to stick with six digits for GNUstep-base but fix the one header that was responsible for pulling in a value of 1080 as the current max value. We could hardcode a current max value of 100800. Also it appears there are some symbols being tested against that aren't even declared in the headers. They appear to be typos because they are so similar to valid symbols. And it appears GNUstep-base hasn't been updated for OS X since 10.6 or 10.7. The file GNUstepBase/GSVersionMacros.h defines these constants, among others. There are no constants that would map to 10.7 or 10.8, but NSCalender.h does use MAC_OS_X_VERSION_10_7. So these tests appear to be broken at the moment. GNUstepBase/GSVersionMacros.h: #ifndef MAC_OS_X_VERSION_10_0 #define MAC_OS_X_VERSION_10_0 10 #define MAC_OS_X_VERSION_10_1 100100 #define MAC_OS_X_VERSION_10_2 100200 #define MAC_OS_X_VERSION_10_3 100300 #define MAC_OS_X_VERSION_10_4 100400 #define MAC_OS_X_VERSION_10_5 100500 #define MAC_OS_X_VERSION_10_6 100600 #endif /* MAC_OS_X_VERSION_10_0 */ Note: these symbols are defined in /usr/include/AvailabilityMacros.h. I
NSUUID patch
Here's a patch I'm working on that implements NSUUID using libuuid. I'm having trouble figuring out what to put in the autoconf.ac. Does anyone know of a template I should look at? I'm sure what I'm doing now isn't correct… : + HAVE_UUID=1 + UUID_CFLAGS=`pkg-config --cflags uuid` + UUID_LIBS=`pkg-config --libs uuid` + + CPPFLAGS=$CPPFLAGS $UUID_CFLAGS + INCLUDE_FLAGS=$INCLUDE_FLAGS $UUID_CFLAGS + LIBS=$UUID_LIBS $LIBS + LDFLAGS=$LDFLAGS $UUID_LIBS + LDIR_FLAGS=$LDIR_FLAGS $UUID_LIBS I'll also need to add a regular AC_CHECK_LIBS check if pkg-config isn't present. Eric NSUUID.diff Description: Binary data ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUStep Themeing - Menu Groove
Hi Aaron,You can get rid of those borders by settingGSMenuVerticalBackground;for example see the (incomplete) Narcissus theme:http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Themes/Narcissus.themeThe relevant part of the theme's Info-gnustep.plist is:GSMenuVerticalBackground = { FileName = Menu.9.png; NinePatch = YES;};Here's the Menu.9.png image (FYI, GNUstep supports Android's 9-patch format):http://svn.gna.org/viewcvs/*checkout*/etoile/trunk/Etoile/Themes/Narcissus.theme/Resources/ThemeTiles/Menu.9.png?revision=5876Screenshot attached, I colored the border inMenu.9.pngred to verify that it works :-)EricOn 2013-06-23, at 1:29 AM, Germán Arias ger...@xelalug.org wrote:On 2013-06-22 06:41:42 -0600 aaroncarr aar.c...@icloud.com wrote:Hi - Im making a gnustep theme and having difficulty styling menu's. I canre-color the menu but i cant get rid of the groove that goes around theedge, more specifically i can get rid of the dark part of the groove on thebottom and right but not the light part at the top and left - can someonegive me a pointer to what i would need to override in GSTheme code to removethe groove !!Thanks!!Screenshot : http://goo.gl/ZFhkTIn Thematic, the color "Control light highlight" changes the color of the linesat left and top. The color "Control dark shadow" changes the lines at right andbottom. But you only can change these color, you can't remove this lines.Germán.___Gnustep-dev mailing listGnustep-dev@gnu.orghttps://lists.gnu.org/mailman/listinfo/gnustep-dev___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSClassSwapper leaving dangling pointers?
Hi Luboš, I'm not too familiar with nib loading internals, but I will try to take a look. Could you upload your work in progress code somewhere? (Or do you have any changes to the original Mac source?) Cool idea to port the unarchiver. :-) Cheers, Eric On Jun 21, 2013 11:30 AM, Luboš Doležel lu...@dolezel.info wrote: Hi, I'm still working on getting the latest The Unarchiver for OS X http://wakaba.c3.cx/s/apps/**unarchiver.htmlhttp://wakaba.c3.cx/s/apps/unarchiver.html working under GNUstep/Darling/Linux and I'm seeing crashes after the application's NIB file is loaded. Now I'm sort of helpless. The crash happens when using the target of a certain NSMenuItem. You can see an excerpt of the relevant NIB's source here; the NSMenuItem clearly refers to the NSPopUpButtonCell that it is part of: object class=NSPopUpButtonCell key=NSCell id=824605593 int key=NSCellFlags-2076180416/int int key=NSCellFlags22048/int reference key=NSSupport ref=170887875/ reference key=NSControlView ref=790450297/ int key=NSButtonFlags109199360**/int int key=NSButtonFlags21/int reference key=NSAlternateImage ref=538669737/ string key=NSAlternateContents/ object class=NSMutableString key=NSKeyEquivalent characters key=NS.bytes/ /object int key=NSPeriodicDelay400/**int int key=NSPeriodicInterval75/**int object class=NSMenuItem key=NSMenuItem id=444300673 reference key=NSMenu ref=552121880/ string key=NSTitledummy/string string key=NSKeyEquiv/ int key=NSKeyEquivModMask**1048576/int int key=NSMnemonicLoc2147483647/int int key=NSState1/int reference key=NSOnImage ref=1019969751/ reference key=NSMixedImage ref=16787521/ string key=NSAction_**popUpItemAction:/string reference key=NSTarget ref=824605593/ /object (Full code can be found in The Unarchiver's source tarball in MainMenu.nib/designable.nib) I can see the target being set correctly via -setTarget upon loading: Breakpoint 3, -[NSMenuItem setTarget:] (self=0x1845808, _cmd=0x77a51eb0 .objc_selector_list+176, anObject=0x1843d58) at NSMenuItem.m:465 465 if (_target == anObject) (gdb) p anObject $15 = (id) 0x1843d58 (gdb) p anObject-isa $16 = (struct objc_class *) 0x77a6bcc0 _OBJC_CLASS_** NSPopUpButtonCell Backtrace: #0 -[NSMenuItem setTarget:] (self=0x189de68, _cmd=0x779f7ce0 .objc_selector_list+640, anObject=0x1429f18) at NSMenuItem.m:465 #1 0x7745354e in -[NSNibControlConnector establishConnection] (self=0x189de38, _cmd=0x77afe330 .objc_selector_list+1232) at NSBundleAdditions.m:177 #2 0x776cfb91 in -[NSIBObjectData nibInstantiateWithOwner:**topLevelObjects:] (self=0x14be778, _cmd=0x77afdf70 .objc_selector_list+272, owner=0xe67488, topLevelObjects=0x0) at GSNibLoading.m:1926 #3 0x776cff26 in -[NSIBObjectData awakeWithContext:] (self=0x14be778, _cmd=0x77b1a170 .objc_selector_list+176, context=0xcb09f8) at GSNibLoading.m:1982 #4 0x7771028e in -[GSNibLoader loadModelData:**externalNameTable:withZone:] (self=0xde8158, _cmd=0x77a56260 .objc_selector_list+224, data=0xeffb58, context=0xcb09f8, zone=0x329060bb38 default_zone) at GSNibLoader.m:87 #5 0x7753f57d in -[NSNib instantiateNibWithExternalName**Table:withZone:] (self=0xecf938, _cmd=0x779f7b00 .objc_selector_list+160, externalNameTable=0xcb09f8, zone=0x329060bb38 default_zone) at NSNib.m:153 #6 0x77453949 in +[NSBundle(NSBundleAdditions) loadNibFile:externalNameTable:**withZone:] (self=0x329057f000 _OBJC_CLASS_NSBundle, _cmd=0x779f7b20 .objc_selector_list+192, fileName=0xf03638, context=0xcb09f8, zone=0x329060bb38 default_zone) at NSBundleAdditions.m:236 #7 0x77454076 in -[NSBundle(NSBundleAdditions) loadNibFile:externalNameTable:**withZone:] (self=0xd406e8, _cmd=0x779f7b20 .objc_selector_list+192, fileName=0xeb5498, context=0xcb09f8, zone=0x329060bb38 default_zone) at NSBundleAdditions.m:342 #8 0x77453b5e in +[NSBundle(NSBundleAdditions) loadNibNamed:owner:] (self=0x329057f000 _OBJC_CLASS_NSBundle, _cmd=0x779db520 .objc_selector_list+688, aNibName=0xeb5498, owner=0xe67488) at NSBundleAdditions.m:277 #9 0x773e2a83 in NSApplicationMain (argc=1, argv=0x7fffd330) at Functions.m:83 So I set up a memory watch for anObject and then I get this: Hardware watchpoint 4: *0x1843d58 Old value = -140067648 New value = -559023410 0x75b81060 in object_setClass () from /usr/lib64/libobjc.so.4.6 (gdb) bt #0 0x75b81060 in object_setClass () from /usr/lib64/libobjc.so.4.6 #1 0x76171b45 in NSDeallocateObject (anObject=0x1843d58) at NSObject.m:855 #2 0x761723fc in -[NSObject dealloc] (self=0x1843d58, _cmd=0x77a00880 .objc_selector_list+2464) at NSObject.m:1385 #3 0x7745ffc1 in -[NSCell dealloc] (self=0x1843d58, _cmd=0x779fc290 .objc_selector_list+1648) at
Re: Position of I-beam cursor
Hi Germán, Not the mouse cursor, is the i-beam cursor. I don't have a Mac to see how this works under Cocoa. But, for example, in this image: http://www.creativetechs.com/iq/tip_images/OSX-Autocomplete.png I imagine the window appears under the word you are typing. So, I need know where is typing the user. Germán. Sounds like a cool project! The I beam is called the insertion point in NSTextView. You can get the character index of it using [self selectedRange] inside NSTextView. The I-beam is only present if length == 0 and location != NSNotFound. To get the (x,y) coordinates for positioning the popup window, you can use -firstRectForCharacterRange:. (NSTextInput protocol). Note that apple's docs say this returns a result in screen coordinates, but our NSTextView's implementation doesn't seem to do that. Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Arrow of NSMenu
Hi Riccardo,
I committed a fix in r36474. What I ended up doing is, when a GSTheme
activates, it takes the image name - path dictionary of images in the theme,
and expands it by applying all of the nsmappings.strings mappings.
So if your theme defines common_3DArrowRight.tiff but not NSMenuArrow, I'll
produce a dictionary like:
{
common_3DArrowRight : path/to/common_3DArrowRight.tiff,
NSMenuArrow : path/to/common_3DArrowRight.tiff,
}
This expanded set of images is then applied to the app state using +[NSImage
_setImagePath:name:], and the same expanded set is unregistered when the theme
deactivates.
Hope this works for you, and the behaviour sounds sensible.
Cheers.
Eric
On 2013-04-05, at 5:25 AM, Riccardo Mottola riccardo.mott...@libero.it wrote:
Hi all,
On 03/28/13 16:40, Eric Wasylishen wrote:
Hey Riccardo, check the nsmappings.strings file in Images. I think that maps
nsmenuarrow to one of the common_ images.
back to the original problem, which is different from what German supposed.
Let's remember that we have a mapping
NSMenuArrow = common_3DArrowRight;
Leaving out Thematic for a moment, I found that placing inside the Theme
Images a an image named
common_3DArrowRight.tif
doesn't work, while putting one called
NSMenuArrow.tif
works fine and the image gets loaded even dynamically when changing the theme.
Riccardo
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Arrow of NSMenu
Hi Fred,
On 2013-04-06, at 9:03 AM, Fred Kiefer fredkie...@gmx.de wrote:
Hi Eric,
I don't like this change very much and will try explain why. This does not
mean that I doubt the technical correctness of this patch. I just think we
should try to find a better solution.
Agreed, it's ugly.
- First off, I don't really see the issue here. This may be because I don't
use themes. But can somebody please explain what would be the problem with
using the official names for images in themes? Riccardo already stated that
things would work when using the name NSMenuArrow.
If we don't use the nsmappings.strings for themes, themes may have to provide a
lot of duplicate files (e..g common_3DArrowRight.tiff, NSMenuArrow.tiff) with
the same contents. Not a huge problem… but it's ugly to have different image
lookup logic for images inside themes and other images.
- The big doubt I am having with the change is that now GSTheme has to know
about that name mapping which was internal to NSImage up to now.
A solution where similar code would be used inside the NSImage method
_setImagePath:name: seems a lot cleaner to me. If we build up that reverse
map you are using, all the necessary information should be available in that
method. I think this would belong into the else case of the if (image != nil)
test you introduced.
I considered that - so +[NSImage _setImagePath:name:] for common_3DArrowRight
would also set the path for NSMenuArrow and anything else that maps to
common_3DArrowRight.
There is a corner case with that; if the theme provides both NSMenuArrow and
common_3DArrowRight, the image used for NSMenuArrow depends on which call to
+[NSImage _setImagePath:name:] is made first.
- Another way to get rid of the problem would be to completely remove the
name mapping from NSImage. I am a bit reluctant to propose this. That
mechanism has been around for a very long time and it allows us to have
clearer names. But with the theme code in place this mechanism isn't needed
that much any more.
I committed a more radical redesign that is much cleaner, I think.
Pasting my changelog comment:
I removed the step in theme activation where we call
+[NSImage _setImagePath:name:] on each image in the theme, and instead
modified +[NSImage _pathForImageNamed:] to also search the theme images
directory.
When a GSTheme activates now, it only calls +[NSImage
_reloadCachedImages]
which checks all NSImage cached by name and reloads any whose path has
changed.
My only worry is whether this will break the GTK or windows themes. IIRC they
replace the NSImage class and override +imageNamed:, so I think they'll still
work.
Eric
Cheers
Fred
On 06.04.2013 10:06, Eric Wasylishen wrote:
Hi Riccardo,
I committed a fix in r36474. What I ended up doing is, when a GSTheme
activates, it takes the image name - path dictionary of images in the
theme, and expands it by applying all of the nsmappings.strings mappings.
So if your theme defines common_3DArrowRight.tiff but not NSMenuArrow, I'll
produce a dictionary like:
{
common_3DArrowRight : path/to/common_3DArrowRight.tiff,
NSMenuArrow : path/to/common_3DArrowRight.tiff,
}
This expanded set of images is then applied to the app state using +[NSImage
_setImagePath:name:], and the same expanded set is unregistered when the
theme deactivates.
Hope this works for you, and the behaviour sounds sensible.
Cheers.
Eric
On 2013-04-05, at 5:25 AM, Riccardo Mottola riccardo.mott...@libero.it
wrote:
Hi all,
On 03/28/13 16:40, Eric Wasylishen wrote:
Hey Riccardo, check the nsmappings.strings file in Images. I think that
maps nsmenuarrow to one of the common_ images.
back to the original problem, which is different from what German supposed.
Let's remember that we have a mapping
NSMenuArrow = common_3DArrowRight;
Leaving out Thematic for a moment, I found that placing inside the Theme
Images a an image named
common_3DArrowRight.tif
doesn't work, while putting one called
NSMenuArrow.tif
works fine and the image gets loaded even dynamically when changing the
theme.
___
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: Cambridge Hackathon
Hey David, Sorry, another of my extraordinarily late replies :-( I'd love to come out for this. Some time in late June / early July sounds good. Cheers, Eric On 2013-02-22, at 6:40 AM, David Chisnall thera...@sucs.org wrote: Hi Everyone, Since we didn't get a DevRoom at FOSDEM this year, there was some discussion about having a hackathon in Cambridge. The term finishes on the 18th of June, after which it is likely to be a lot easier to put people up in college accommodation. Who would be interested, and what are your date preferences? David -- Sent from my IBM 1620 ___ 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: Creating PDF reports
Hey Fred, Steven, I did a little debugging of this and GSPDFPrintOperation was broken; it was not writing the results into _data, and was overriding -_print but not calling -beginDocument which sets up the PDF context. I made a quick fix for these problems. The remaining problem is the output is up-side-down compared with running Steven's code on OS X. Steven, if you grab the latest gnustep-gui code from svn, you should get at least the up-side-down pdf output. Cheers, Eric On 2013-02-28, at 3:32 AM, Fred Kiefer fredkie...@gmx.de wrote: On 28.02.2013 03:48, Steven LeMaire wrote: I've gotten a bit further along with this (I had a small problem in my main.m) with the Xvfb method. Apologies for the long output, but basically it runs to completion now, except the pdf file it creates is empty. Which GNUstep backend are you using? PDF output should only be supported by the cairo backend. Please check the config.log from GNUstep back for this. You probably should check your program first on a machine with an actual X system, to make sure no windows pop up. And only if this works without requiring user interaction, transfer the program to a machine without user interface. ___ 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: display problem on x86-64bit / cairo
Hey Fred, David, I haven't had much time to work on GNUstep in the past few months but just want to say I will try to help out with this! For gstates, if I understand the semantics correctly, we can use the code from our cairo backend for copying and restoring the graphics state to/from an object, but only when the user does explicit save/restore. For normal pushes/pops, we can just use the current opal implementation which is basically a cairo_save/cairo_restore with a bit of extra bookkeeping. Regards, Eric On 2013-02-02, at 3:46 PM, Fred Kiefer fredkie...@gmx.de wrote: Sounds like a plan we all agree on. I will make the DPS changes next week and then start to work on the Opal bavkend together with Ivan. There are two open issues I know about, font handling and stored gstates. For both we need a solution before that backend is fully working, the rest should be fairly simple. Fred On the road Am 02.02.2013 um 07:48 schrieb David Chisnall thera...@sucs.org: On 1 Feb 2013, at 16:55, Ivan Vučica wrote: Moving to an Opal backend and then making the graphics context available via -[NSGraphicsContext graphicsPort] would be something I wouldn't oppose in any way. I wonder why ;-) Using the CoreGraphics API as our back end interface is definitely something that I would support in the medium to long term, but it requires a fair bit of work. Just changing the DPS functions to CGFloat for now and getting an Opal back end that uses the CoreGraphics APIs would be a good start. David -- Sent from my Apple II ___ 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: Drawing context
Hey Riccardo, I committed an implementation of -isDrawingToScreen for cairo and tested that graphos no longer prints the selection handles to PDFs. :-) -Eric On 2012-09-26, at 6:29 AM, Riccardo Mottola riccardo.mott...@libero.it wrote: Hi, Greg reported me bug about Graphos and I think it is a GS bug, since it works on Mac. During printing, objects should not drawn their editors (= shape or path handles). To do that, I use: if ([[NSGraphicsContext currentContext] isDrawingToScreen]) [editor draw]; thus I suppose that on GS (cairo backend at least) it returns true even while printing. Testing is simple: Launch graphos, select some shape, look at the handles, print (preview). The handles should not print. They do on GS, they don't on mac. The bug appears to be backend specific: it works on xlib but not on cairo. Riccardo ___ Discuss-gnustep mailing list discuss-gnus...@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Couple of problems with current SVN
Hey German, I can reproduce the problem where directories with accented characters show up incorrectly in the open/save panels. I created a directory with an accented é using gnome, and it shows up in the gnustep open panel as Å©. I debugged this, and basically it's a configuration issue: the filenames returned by the posix readdir() function are being interpreted using +[NSString defaultCStringEncoding] , which is Latin-1 by default unless the GNUSTEP_STRING_ENCODING environment var is set. Try running: export GNUSTEP_STRING_ENCODING=NSUTF8StringEncoding before Ink, and see if it fixes the problem - it did for me. Maybe we should change +[NSString defaultCStringEncoding] to NSUTF8StringEncoding? Cheers, Eric On 2012-06-02, at 8:01 PM, Germán A. Arias wrote: Well, to investigate the problem of the directories names in panels Open/Save, I added in NSBrowser.m: NSLog(@Path: %@, path); at line 460. And: NSLog(@SubStrings: %@, [subStrings description]); at line 481. Now run Ink and then the Open panel in a directory that contains the letter á. This is the output: 2012-06-02 17:47:45.806 Ink[18900] Path: /home/german/Imágenes 2012-06-02 17:47:45.927 Ink[18900] SubStrings: (home, german, Im\U00C3 \U00A1genes) This is not what I would expect for the method -componentsSeparatedByString:. (This is the method to make the subStrings array in line 578.). ___ 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: Couple of problems with current SVN
P.S., It seems that glib interpretes filenames as utf-8 by default, but like GNUstep, has an environment variable for configuring that. http://developer.gnome.org/glib/stable/glib-Character-Set-Conversion.html#g-get-filename-charsets -Eric On 2012-06-02, at 10:14 PM, Eric Wasylishen wrote: Hey German, I can reproduce the problem where directories with accented characters show up incorrectly in the open/save panels. I created a directory with an accented é using gnome, and it shows up in the gnustep open panel as Å©. I debugged this, and basically it's a configuration issue: the filenames returned by the posix readdir() function are being interpreted using +[NSString defaultCStringEncoding] , which is Latin-1 by default unless the GNUSTEP_STRING_ENCODING environment var is set. Try running: export GNUSTEP_STRING_ENCODING=NSUTF8StringEncoding before Ink, and see if it fixes the problem - it did for me. Maybe we should change +[NSString defaultCStringEncoding] to NSUTF8StringEncoding? Cheers, Eric On 2012-06-02, at 8:01 PM, Germán A. Arias wrote: Well, to investigate the problem of the directories names in panels Open/Save, I added in NSBrowser.m: NSLog(@Path: %@, path); at line 460. And: NSLog(@SubStrings: %@, [subStrings description]); at line 481. Now run Ink and then the Open panel in a directory that contains the letter á. This is the output: 2012-06-02 17:47:45.806 Ink[18900] Path: /home/german/Imágenes 2012-06-02 17:47:45.927 Ink[18900] SubStrings: (home, german, Im\U00C3 \U00A1genes) This is not what I would expect for the method -componentsSeparatedByString:. (This is the method to make the subStrings array in line 578.). ___ 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: Getting Objective-C 2.0 working
Hi Laurent,
To use blocks in GNUstep you need to use the GNUstep Objective-C runtime,
a.k.a. libobjc2, whose releases are available here:
http://download.gna.org/gnustep/
Unfortunately, I don't think this library is available in debian/ubuntu (though
I could be wrong!). Confusingly, the package called libobjc2 in debian/ubuntu
is unrelated to the GNUstep Objective-C runtime and doesn't support blocks.
So, as far as I know, what you'll need to do is remove the Ubuntu packages for
gnustep you installed, then install libobjc2 and GNUstep again from the source
packages. (Latest gnustep releases are at:
http://wwwmain.gnustep.org/resources/downloads.php)
The Etoile ObjectiveC2 framework no longer exists and isn't something you need
to worry about. IIRC, the initial support in GNUstep for the modern Objective-C
runtime api's was started in that framework in Etoile, but that code has since
been merged into GNUstep and libobjc2.
Hope this helps,
Eric
On 2012-05-17, at 9:27 PM, Laurent Michel wrote:
Dear All,
I develop on MaOS and would love to port my code to Linux. Essentially, I use
Objective-C 2.0 with clang as a compiler.
I created an Ubuntu 12.04 VM under VMWare and installed GNUStep through that
channel. I compiled a silly hello world and that worked fine.
My problems started when I tried to compile my own code which makes *heavy*
use of Objective-C blocks. I always end-up seeing this message:
clang -I/usr/GNUstep/System/Library/Headers -fblocks -fobjc-nonfragile-abi
-c CPFactory.m
In file included from CPFactory.m:27:
In file included from ./CPFactory.h:27:
In file included from
/usr/GNUstep/System/Library/Headers/Foundation/Foundation.h:30:
/usr/GNUstep/System/Library/Headers/GNUstepBase/GSVersionMacros.h:287:14:
fatal error: 'objc/blocks_runtime.h' file not found
namely, it cannot find objc/blocks_runtime.h
I started googling around and I found lots of conflicting information on the
topic as well as reference to Etoile, and ObjectiveC2 (a framework) but it
seems largely incompatible with GNUStep. I'll looking for some directions to
get going with a simple code that uses blocks. For instance, a silly test
like:
#import Foundation/NSObject.h
int foo(int (^b)(int)) {
return b(5);
}
int main() {
int y = 10;
int z = foo(^(int x) {
return y + x;
});
NSLog(@result is %d\n,z);
}
Should compile and run when linked against the Foundation framework.
Any pointer is greatly appreciated.
--
Laurent
___
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: Keyboard problem
Great! I committed the patch with only a slight change, to use the proper check for Xutf8LookupString. Eric On 2012-05-12, at 8:05 AM, Germán A. Arias wrote: El Fri, 11 May 2012 21:24:20 -0600 Eric Wasylishen ewasylis...@gmail.com escribió: Hey German, I investigated a similar problem a while ago. My test case was setting the keyboard layout in gnome on Ubuntu 12.04 to French, using the Ubuntu gui for changing keyboard layouts. This was on a physically US English keyboard, and I was getting similar output in Ink when pressing a key that should have produced an accented e or a. I traced the problem to Source/x11/XIMInputServer.m, in particular, it does some things with setting the C locale which didn't make sense to me based on reading the documentation of the relevant XIM functions. In my case, the existing XIMInputServer code was not calling Xutf8LookupString when it should have. Here is a patch that cleans up XIMInputServer a bit. Assuming this fixes it for you - before the patch can be committed there also needs to be a configure check for the Xutf8LookupString function (HAVE_XUTF8LOOKUPSTRING) added - IIRC it is a relatively recent addition to Xorg. Cheers, Eric :) The patch solve the problem, with XIM enabled. With --disable-xim, if I want write á I get ´a . But this is expected since the patch is just for XIM server. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Keyboard problem
Hey German, I investigated a similar problem a while ago. My test case was setting the keyboard layout in gnome on Ubuntu 12.04 to French, using the Ubuntu gui for changing keyboard layouts. This was on a physically US English keyboard, and I was getting similar output in Ink when pressing a key that should have produced an accented e or a. I traced the problem to Source/x11/XIMInputServer.m, in particular, it does some things with setting the C locale which didn't make sense to me based on reading the documentation of the relevant XIM functions. In my case, the existing XIMInputServer code was not calling Xutf8LookupString when it should have. Here is a patch that cleans up XIMInputServer a bit. Assuming this fixes it for you - before the patch can be committed there also needs to be a configure check for the Xutf8LookupString function (HAVE_XUTF8LOOKUPSTRING) added - IIRC it is a relatively recent addition to Xorg. Cheers, Eric On Fri, May 11, 2012 at 5:56 AM, Germán A. Arias ger...@xelalug.org wrote: Each time I launch a gnustep app, I get this message: Unable to initialize XIM, using standard keyboard events So, If I type something like á on Ink, I get A'a. Is this something wrong on my configuration? or is a bug on gnustep? Attached test log for base, where I have 5 test fail. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev back-input-fix.diff Description: Binary data ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: some unsigned/NSInteger to NSUInteger changes in -gui
Hi,
What's safe is encoding with any supported integer type and decoding with
another integer type, so you can write a keyed archive with @encode(long) and
decode it as @encode(int), even if long is 64-bits and int is 32-bits.
In other words it's safe to use @encode(NS[U]Integer). However, if the ivar is
changed to NSUInteger, I think these:
- [aCoder encodeValueOfObjCType: i at: _selected_item];
+ [aCoder encodeValueOfObjCType: I at: _selected_item];
- [aDecoder decodeValueOfObjCType: i at: _selected_item];
+ [aDecoder decodeValueOfObjCType: I at: _selected_item];
should actually use @encode(NSUInteger), not l. Otherwise the patch looks
good :-).
Eric
On 2012-04-09, at 11:08 AM, Fred Kiefer wrote:
Most of the patch is ok, but we have too ake a careful look at the coding
change. This may break backwards and forewards compatibility. Maybe Richard
is able to explain if this change is save or not.
Fred
On the road
Am 09.04.2012 um 18:02 schrieb Sebastian Reitenbach
sebas...@l00-bugdead-prods.de:
Hi,
while looking at compilation warnings from the latest releases, I found in
-gui (svn) some parts in NSTableView that would need to be changed. First is
easy, declare i as NSUInteger (was unsigned before). Further I think
_selected_item declared in the header as NSInteger also should be a
NSUInteger.
is it OK when I commit the patch?
Sebastian
Index: Source/NSTabView.m
===
--- Source/NSTabView.m(revision 35049)
+++ Source/NSTabView.m(working copy)
@@ -123,7 +123,7 @@
- (void) removeTabViewItem: (NSTabViewItem*)tabViewItem
{
- unsigned i = [_items indexOfObject: tabViewItem];
+ NSUInteger i = [_items indexOfObject: tabViewItem];
if (i == NSNotFound)
return;
@@ -202,7 +202,7 @@
- (void) selectNextTabViewItem: (id)sender
{
- if ((_selected_item != NSNotFound) ((unsigned)(_selected_item + 1)
[_items count]))
+ if ((_selected_item != NSNotFound) ((_selected_item + 1) [_items
count]))
{
[self selectTabViewItemAtIndex: _selected_item + 1];
}
@@ -550,7 +550,7 @@
[aCoder encodeValueOfObjCType: @encode(BOOL) at: _draws_background];
[aCoder encodeValueOfObjCType: @encode(BOOL) at: _truncated_label];
[aCoder encodeConditionalObject: _delegate];
- [aCoder encodeValueOfObjCType: i at: _selected_item];
+ [aCoder encodeValueOfObjCType: I at: _selected_item];
}
}
@@ -631,7 +631,7 @@
[aDecoder decodeValueOfObjCType: @encode(BOOL) at: _draws_background];
[aDecoder decodeValueOfObjCType: @encode(BOOL) at: _truncated_label];
_delegate = [aDecoder decodeObject];
- [aDecoder decodeValueOfObjCType: i at: _selected_item];
+ [aDecoder decodeValueOfObjCType: I at: _selected_item];
_selected = [_items objectAtIndex: _selected_item];
}
return self;
Index: Headers/AppKit/NSTabView.h
===
--- Headers/AppKit/NSTabView.h(revision 35049)
+++ Headers/AppKit/NSTabView.h(working copy)
@@ -54,7 +54,7 @@
BOOL _draws_background;
BOOL _truncated_label;
id _delegate;
- NSInteger _selected_item;
+ NSUInteger _selected_item;
}
- (void)addTabViewItem:(NSTabViewItem *)tabViewItem;
- (void)insertTabViewItem:(NSTabViewItem *)tabViewItem
___
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
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: In-window menu black bar in Xfce
Sounds like it might be this bug: https://savannah.gnu.org/bugs/?35901 -Eric On 2012-04-07, at 7:02 AM, Germán A. Arias wrote: El Fri, 6 Apr 2012 23:26:00 -0600 Germán A. Arias ger...@xelalug.org escribió: With current SVN I have a problem with in-window menu when the window use frame from string. In Gemas.app you can set the size of the editor. If you change the height, the next time you open gemas the menu is wrong. A black bar appears above the menu. You need resize the window to correct this. This is in Xfce. I don't know if this is a current problem, since in Gnome I don't had this problem. But seems like when the window is redraw this is done in a wrong way. I get the frame and put it in the window from the -awakeFromNib: method. Because the last time I try do it from the gorm file don't worked. Seems like change the size at -awakeFromNib at document class isn't a good idea. But moving the corresponding code to the delegate method -winwodDidBecomeMainWindow: solve the problem. So I think that is important remember that any change in the size of a window that can display a menu, should be done after it become the main window. ___ 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: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.m
Hi, any other thoughts on this? I still think my proposed solution is the best
option: changing systemVersion to a fixed integer, and only incrementing it
when we make changes that break compatibility.
i.e. change NSCoder.m:
- (unsigned) systemVersion
{
return (((GNUSTEP_BASE_MAJOR_VERSION * 100)
+ GNUSTEP_BASE_MINOR_VERSION) * 100) + GNUSTEP_BASE_SUBMINOR_VERSION;
}
to:
- (unsigned) systemVersion
{
// Please increment when you make a change to the archive format
// that any older versions of the library won't be able to read, and
return 4;
}
We could also make a change in NSUnarchiver to check if the version of the
archive being read is greater than NSCoder's systemVersion, in which case we
won't be able to read the archive and can throw an exception (?).
-Eric
On 2012-03-07, at 4:00 PM, Eric Wasylishen wrote:
Hm… to me it would make more sense if systemVersion was an arbitrary number
that we increment only when we make a change to the archive format.
If I understand it correctly, with the current scheme, an old version of
gnustep-base can't tell if it is able to read an archive or not (it doesn't
know that at 1.24.2 there was a change to the archive format). If we use
arbitrary numbers, incremented when a format change is made, an old version
of gnustep-base can tell for sure whether it can safely read an archive saved
by a newer version of gnustep-base.
Eric
On 2012-03-07, at 1:16 AM, Richard Frith-Macdonald wrote:
On 6 Mar 2012, at 09:32, Fred Kiefer wrote:
There don't seem to be anyone using Gorm on OpenBSD from the packages.
I'd guess, otherwise, the problem would have shown up much earlier.
Therefore I'm not sure, whether there is a real need to fix that in
-base. But I definitely
should fix it in the Ports/Packages.
I think you are wrong here. The mismatch of the archive numbers could not
have caused any problem before the change to NSArchiver. This means, we
don't know if any gorm files or other archives made on OpenBSD are
affected. We have to plan for the worst and try to come up with a solution
that allows for these archives to be read in correctly.
I would like to propose an over cautious solution: We decouple the archiver
systemVersion from the library version and make it bigger than any number
already used on OpenBSD, lets say, library version + 4 (= 5.24.2). And make
this the version that gets special treatment in NSArchiver, plus of course
1.24.2 (hopefully this specific number hasn't been used on OpenBSD), as we
already have new archives produced with that number. And on OpenBSD, we
need to guaranty that such mixing of version numbering never happens again.
We also need to investigate the whole base code, whether there is another
place where we might have such a mix.
I've been thinking about this ... I really don't like the idea of separating
the value returned by -systemVersion from the version of the system ... it
just seems wrong.
This is simply a bug in the OpenBSD package, nothing to do with GNUstep
directly ... but we ought to do a workaround.
What I'd suggest is a temporary hack (meaning we should remove it in a few
years) to recognise version 4.0.0 as actually meaning 1.24.1 unless the
current system version is 4.0.0 or later, so that decoding old archives
works (though we should probably report the incident using NSLog()).
Given that our version numbering increases really slowly, I wouldn't expect
us to actually get to version 4.0.0 for several years, by which time old
OpenBSD specific archives should not be an issue.
___
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: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.m
Hm… to me it would make more sense if systemVersion was an arbitrary number that we increment only when we make a change to the archive format. If I understand it correctly, with the current scheme, an old version of gnustep-base can't tell if it is able to read an archive or not (it doesn't know that at 1.24.2 there was a change to the archive format). If we use arbitrary numbers, incremented when a format change is made, an old version of gnustep-base can tell for sure whether it can safely read an archive saved by a newer version of gnustep-base. Eric On 2012-03-07, at 1:16 AM, Richard Frith-Macdonald wrote: On 6 Mar 2012, at 09:32, Fred Kiefer wrote: There don't seem to be anyone using Gorm on OpenBSD from the packages. I'd guess, otherwise, the problem would have shown up much earlier. Therefore I'm not sure, whether there is a real need to fix that in -base. But I definitely should fix it in the Ports/Packages. I think you are wrong here. The mismatch of the archive numbers could not have caused any problem before the change to NSArchiver. This means, we don't know if any gorm files or other archives made on OpenBSD are affected. We have to plan for the worst and try to come up with a solution that allows for these archives to be read in correctly. I would like to propose an over cautious solution: We decouple the archiver systemVersion from the library version and make it bigger than any number already used on OpenBSD, lets say, library version + 4 (= 5.24.2). And make this the version that gets special treatment in NSArchiver, plus of course 1.24.2 (hopefully this specific number hasn't been used on OpenBSD), as we already have new archives produced with that number. And on OpenBSD, we need to guaranty that such mixing of version numbering never happens again. We also need to investigate the whole base code, whether there is another place where we might have such a mix. I've been thinking about this ... I really don't like the idea of separating the value returned by -systemVersion from the version of the system ... it just seems wrong. This is simply a bug in the OpenBSD package, nothing to do with GNUstep directly ... but we ought to do a workaround. What I'd suggest is a temporary hack (meaning we should remove it in a few years) to recognise version 4.0.0 as actually meaning 1.24.1 unless the current system version is 4.0.0 or later, so that decoding old archives works (though we should probably report the incident using NSLog()). Given that our version numbering increases really slowly, I wouldn't expect us to actually get to version 4.0.0 for several years, by which time old OpenBSD specific archives should not be an issue. ___ 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: GNUstep's GTK theme now changes when user selects a new theme...
Hi Greg, I think I fixed the problem.. the GTK theme was forgetting to remove the existing slider/radio/switch images by calling -setName: nil, so the replacement images weren't being registered since [NSImage setName:] does nothing if the name is already in use. In the longer term I'd like to come up with a more clearly defined API on NSImage for updating system images programatically. Currently GSTheme uses the +_setImagePath:name: method used when loading image files in theme bundles. Maybe something like: +[NSImage registerThemeImage: (NSImage *)anImageGeneratedByTheTheme forName: (NSString *)aName]; This could use the same type of trick that +_setImagePath:name: does of reusing the existing registered NSImage instance, removing all of its reps, and copying in the reps from anImageGeneratedByTheTheme. Eric On 2012-03-05, at 11:07 PM, Gregory Casamento wrote: I recently made changes so that GNUstep's GTK theme now changes when user selects a new theme. There's one problem, though... It seems like the buttons for the sliders, the switch and the radio buttons don't update when the theme is changed. For some reason these images are not reloaded (even though they are surely generated when the theme is loaded/reloaded). So, therefore, the new images which are regenerated after the initial load are not taking effect. I'm wondering if anyone has a clue about this. GC -- Gregory Casamento Open Logic Corporation, Principal Consultant yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) http://www.gnustep.org http://heronsperch.blogspot.com ___ 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: Fix NSConnection bug on 64 bits archs
Thanks, I fixed this and several other instances in base where
NSNotFound was read from or stored in an unsigned or int variable.
(I didn't change the c variable here to NSUInteger because I don't
think it's strictly necessary - a lot of NSConnection code uses
unsigned - but it could be a good idea)
Eric
On Mon, Mar 5, 2012 at 8:57 AM, Philippe Roussel p.o.rous...@free.fr wrote:
Hi,
Lucas Schnorr ran into the following problem (I can reproduce it too) :
2012-03-05 10:08:26.409 tobjc[6709] Problem posting notification:
NSException: 0x7f22d8005658 NAME:NSRangeException REASON:Index -1 is
out of range 1 (in 'objectAtIndex:') INFO:{Array = (NSRunLoop:
0x1cfe998); Count = 1; Index = 4294967295; }
NSConnection was probably forgotten when NSArray was moved to NSUInteger. I
think the following patch is needed :
Index: Source/NSConnection.m
===
--- Source/NSConnection.m (révision 34875)
+++ Source/NSConnection.m (copie de travail)
@@ -1583,11 +1583,11 @@
GS_M_LOCK(IrefGate);
if (IrunLoops != nil)
{
- unsigned pos = [IrunLoops indexOfObjectIdenticalTo: loop];
+ NSUInteger pos = [IrunLoops indexOfObjectIdenticalTo: loop];
if (pos != NSNotFound)
{
- unsigned c = [IrequestModes count];
+ NSUInteger c = [IrequestModes count];
while (c-- 0)
{
Philippe
___
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: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.m
On 2012-02-27, at 3:35 AM, Richard Frith-Macdonald wrote: On 27 Feb 2012, at 08:09, Fred Kiefer wrote: On 27.02.2012 03:12, Eric Wasylishen wrote: Author: ericwa Date: Mon Feb 27 03:12:19 2012 New Revision: 34822 URL: http://svn.gna.org/viewcvs/gnustep?rev=34822view=rev Log: * Source/NSData.m: Various 64-bit compatibility fixes, mostly changing unsgined to NSUInteger. Modified: libs/base/trunk/ChangeLog libs/base/trunk/Source/NSData.m If I checked correctly this patch changed the on disk representation of NSData for archiving on 64bit systems. You changed the encoding of length from unsigned int to NSUInteger and if the underlying archiver doesn't take care of this (Richard, is this the case? Then this mail is pointless), this will result in a different representation. Normally we have to increase the version number for the class to handle such a change and provide different decoding paths for the different versions. NSArchiver/NSUnarchiver stuff in GNUstep should tolerate different sizes of integers (a feature introduced many years ago to handle systems with different encodings for different word sizes), so encoding an NSUInteger instead of an unsigned should be OK. But, this introduced an inconsistency in that it would encode NSData with an 'unsigned' value (via the special methods in the coder/decoder for handling NSData), but now encoding must bale data allowing larger data objects (on 64bit systems). I therefore modified NSArchiver/NSUnarchive for consistency ... though I haven't actually tried archiving/unarching data objects that large. Hm, I seem to be getting lots of test failures now (on 64-bit linux). Testing basictypes.m... Running base/coding/basictypes.m... ./obj/basictypes: Uncaught exception NSInternalInconsistencyException, reason: expected array count 27 and got 116002156320 /usr/local/bin/gnustep-tests: line 300: 22653 Aborted $RUN_CMD Failed file: basictypes.m aborted without running all tests! Testing decoding.m... Running base/coding/decoding.m... Passed test: decoding.m:198 ... decoding current version of class NSArray Failed test: decoding.m:230 ... decoding class NSArray: NSException: 0x82bc38 NAME:NSInternalInconsistencyException REASON:expected array count 2 and got 9395417345 INFO:(null) … etc … I think the problem is, in -[NSUnarchiver decodeArrayOfObjCType:count:at:], it calls -[NSData deserializeDataAt:ofObjCType:atCursor:context:] which doesn't do the automatic handling of 32-bit vs 64-bit. So if NSUInteger is 64-bits, decodeArrayOfObjCType:count:at: will attempt to read a 64-bit array length value even if the archive only has a 32-bit length value stored there. Not sure what the solution is… seems to me like you would need a new archive format where array lengths are always stored as 64-bits. But my changes in NSData should be safe without the NSArchiver/NSUnarchiver changes, I think? Cheers, Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.m
(NSBundleAdditions) loadNibFile:externalNameTable:withZone:] (self=optimized out, _cmd=optimized out, fileName=optimized out, context=0xa78908, zone=0x775d6fc0) at NSBundleAdditions.m:235 #24 0x777d4937 in NSApplicationMain (argc=optimized out, argv=optimized out) at Functions.m:83 #25 0x766e430d in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #26 0x00401205 in _start () (gdb) I did a complete uninstall and rebuild of everything so I'm certain gdnc, gpbs, etc. are all up to date. --Eric On Mon, Feb 27, 2012 at 2:08 PM, Richard Frith-Macdonald rich...@tiptree.demon.co.uk wrote: On 27 Feb 2012, at 20:41, Eric Wasylishen wrote: Sorry to bug you more, but here's another weird thing: Any idea how this gorm archive could have a version of 4? (0x9c40) http://cvs.savannah.gnu.org/viewvc/gap/system-apps/Zipper/Resources/MainMenu.gorm/objects.gorm?root=gapview=markup No ... I'll see if I can spot anything. I just tried opening Zipper.app and got an exception because the archive version was triggering the new code path. Also, should we bump the GNUSTEP_BASE_SUBMINOR_VERSION so archives saved with gnustep-base trunk between the last release and now will continue to work? That sounds reasonable ... I'll do it. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: setlocale() [Was: Re: NSNumberFormater test fails]
Hi, I committed a slightly modified version of locale3.diff. This fixes the NSNumberFormatter test failures when a non-English locale is used (I tested French). Let me know if you have any problems with this. -Eric On 2012-02-12, at 6:25 PM, Robert Slover wrote: Honestly this seem right to me, or at least safest, particularly for library code. There are too many fundamental APIs that encapsulate the current locale as part of their internal state without being able to preserve it. A good example would be a compiled regular expression -- bad things happen if the locale changes after the regular expression is parsed and compiled but before it is used. This is one of the current weaknesses of POSIX, IMHO. --Robert On Feb 12, 2012, at 15:31, Fred Kiefer fredkie...@gmx.de wrote: That means you were right, Cocoa doesn't call setlocale(LC_ALL, ) automatically. I am actually surprised by that, but if they don't do neither should we. Fred On 11.02.2012 00:40, Eric Wasylishen wrote: Btw, I attached a test program test.m which shows how the current AppKit locale (and libc locale) affects various ways of printing decimal points: Mac OS 7.2, locale set to French Canadian in SystemPreferences: new-host-2:~ ericw$ echo $LANG fr_CA.UTF-8 new-host-2:~ ericw$ gcc test.m -framework Foundation -framework AppKit new-host-2:~ ericw$ ./a.out 2012-01-29 17:52:58.642 a.out[1215:707] Launched. current locale: fr_CA 2012-01-29 17:52:58.643 a.out[1215:707] NSLog Decimal test: 1.23 printf decimal test: 1.23 2012-01-29 17:52:58.644 a.out[1215:707] Calling setlocale(LC_ALL, )... 2012-01-29 17:52:58.645 a.out[1215:707] NSLog bonjour! 1.23 printf bonjour! 1,23 2012-01-29 17:52:58.645 a.out[1215:707] -[NSString stringWithFormat:]: 1.23 ^C GNUstep trunk: ericwa@ericwa-VirtualBox:~$ export LC_ALL=fr_CA.UTF-8 ericwa@ericwa-VirtualBox:~$ gcc `gnustep-config --objc-flags` test.m `gnustep-config --gui-libs` -o test ericwa@ericwa-VirtualBox:~$ ./test 2012-02-10 16:16:32.203 test[14990] Launched. current locale: fr_CA 2012-02-10 16:16:32.210 test[14990] NSLog Decimal test: 1.23 printf decimal test: 1,23 2012-02-10 16:16:32.211 test[14990] Calling setlocale(LC_ALL, )... 2012-02-10 16:16:32.211 test[14990] NSLog bonjour! 1.23 printf bonjour! 1,23 2012-02-10 16:16:32.211 test[14990] -[NSString stringWithFormat:]: 1.23 The only difference is the first printf decimal test: on GNUstep uses the comma decimal separator, because of the setlocale called by +[NSObject initialize]. On Mac OS, the libc locale is still C. One interesting thing is neither NSLog nor -[NSString stringWithFormat:], on Cocoa or GNUstep, use the locale's decimal point (regardless of the setting of the AppKit locale, or the libc locale.) On 2012-02-08, at 12:29 PM, Fred Kiefer wrote: I think you are right as far as ICU is concerned, when we use ICU we should use the function uloc_setDefault() to select the locale we want. But currently the code we have is not ICU only, it works with a mixture of ICU and glibc and it should work without ICU. We could try to make sure that all our calls that need locale information of any sort, go through a wrapper that uses the corresponding ICU function when that is available. If that is achieved we could only use uloc_setDefault(), when ICU gets used and everything should work. (And fall back to the old setlocale() call in the other case. But is this achievable? Who is willing to check which of our used glibc functions use any locale information? And to rewrite all of these? Just think of the work in NSLog and the removal of all printf calls and the like. Actually, I don't think there would be much work to do. From what I've seen, gnustep-base doesn't use the libc locale system much (if at all). For example, GSFormat.m uses NSLocale to get the decimal separator character (it does have fallback code to print a decimal using printf, but from what I can see that will never get used.) The only place I've found the libc locale used is in GSLocale.m, in the implementation of GSDomainFromDefaultLocale(). I attached a first try at a patch which does the following: - deprecates GSSetLocale and GSSetLocaleC - they now do nothing. - removes the call to GSSetLocaleC in +[NSObject initialize]. - adds a function to GSLocale.m, GSDefaultLanguageLocale(), which returns the locale for LC_MESSAGES. refactors two parts of NSUserDefaults that were calling GSSetLocale to get LC_MESSAGES to use GSDefaultLanguageLocale() instead. - rewrite parts of GSLocale.m which need to use the libc locale. Now they call setlocale(LC_ALL, ), and afterwards restore the C locale to what it was previously. Of course if we were to apply this I would want to do a more careful scan of base for uses of the libc locale. I am not that sure whether the selection of the locale is really up to the application code. When an application gets
Re: setlocale() [Was: Re: NSNumberFormater test fails]
Btw, I attached a test program test.m which shows how the current AppKit locale (and libc locale) affects various ways of printing decimal points: Mac OS 7.2, locale set to French Canadian in SystemPreferences: new-host-2:~ ericw$ echo $LANG fr_CA.UTF-8 new-host-2:~ ericw$ gcc test.m -framework Foundation -framework AppKit new-host-2:~ ericw$ ./a.out 2012-01-29 17:52:58.642 a.out[1215:707] Launched. current locale: fr_CA 2012-01-29 17:52:58.643 a.out[1215:707] NSLog Decimal test: 1.23 printf decimal test: 1.23 2012-01-29 17:52:58.644 a.out[1215:707] Calling setlocale(LC_ALL, )... 2012-01-29 17:52:58.645 a.out[1215:707] NSLog bonjour! 1.23 printf bonjour! 1,23 2012-01-29 17:52:58.645 a.out[1215:707] -[NSString stringWithFormat:]: 1.23 ^C GNUstep trunk: ericwa@ericwa-VirtualBox:~$ export LC_ALL=fr_CA.UTF-8 ericwa@ericwa-VirtualBox:~$ gcc `gnustep-config --objc-flags` test.m `gnustep-config --gui-libs` -o test ericwa@ericwa-VirtualBox:~$ ./test 2012-02-10 16:16:32.203 test[14990] Launched. current locale: fr_CA 2012-02-10 16:16:32.210 test[14990] NSLog Decimal test: 1.23 printf decimal test: 1,23 2012-02-10 16:16:32.211 test[14990] Calling setlocale(LC_ALL, )... 2012-02-10 16:16:32.211 test[14990] NSLog bonjour! 1.23 printf bonjour! 1,23 2012-02-10 16:16:32.211 test[14990] -[NSString stringWithFormat:]: 1.23 The only difference is the first printf decimal test: on GNUstep uses the comma decimal separator, because of the setlocale called by +[NSObject initialize]. On Mac OS, the libc locale is still C. One interesting thing is neither NSLog nor -[NSString stringWithFormat:], on Cocoa or GNUstep, use the locale's decimal point (regardless of the setting of the AppKit locale, or the libc locale.) On 2012-02-08, at 12:29 PM, Fred Kiefer wrote: I think you are right as far as ICU is concerned, when we use ICU we should use the function uloc_setDefault() to select the locale we want. But currently the code we have is not ICU only, it works with a mixture of ICU and glibc and it should work without ICU. We could try to make sure that all our calls that need locale information of any sort, go through a wrapper that uses the corresponding ICU function when that is available. If that is achieved we could only use uloc_setDefault(), when ICU gets used and everything should work. (And fall back to the old setlocale() call in the other case. But is this achievable? Who is willing to check which of our used glibc functions use any locale information? And to rewrite all of these? Just think of the work in NSLog and the removal of all printf calls and the like. Actually, I don't think there would be much work to do. From what I've seen, gnustep-base doesn't use the libc locale system much (if at all). For example, GSFormat.m uses NSLocale to get the decimal separator character (it does have fallback code to print a decimal using printf, but from what I can see that will never get used.) The only place I've found the libc locale used is in GSLocale.m, in the implementation of GSDomainFromDefaultLocale(). I attached a first try at a patch which does the following: - deprecates GSSetLocale and GSSetLocaleC - they now do nothing. - removes the call to GSSetLocaleC in +[NSObject initialize]. - adds a function to GSLocale.m, GSDefaultLanguageLocale(), which returns the locale for LC_MESSAGES. refactors two parts of NSUserDefaults that were calling GSSetLocale to get LC_MESSAGES to use GSDefaultLanguageLocale() instead. - rewrite parts of GSLocale.m which need to use the libc locale. Now they call setlocale(LC_ALL, ), and afterwards restore the C locale to what it was previously. Of course if we were to apply this I would want to do a more careful scan of base for uses of the libc locale. I am not that sure whether the selection of the locale is really up to the application code. When an application gets started it has a right to expect that its supporting libraries are set up to a sensible default. This may not be true for tools, but should be the case for applications that display a user interface. I agree with your basic point… but I would expect the GNUstep locale system to be set up, not the libc locale. Eric locale3.diff Description: Binary data test.m Description: Binary data On 08.02.2012 19:25, Eric Wasylishen wrote: Hi, I just had a look in to this problem. While it sounds like there is certainly a bug in libicu - it should not break if the libc locale is changed - I am very skeptical that setting the libc locale as we do in +[NSObject initialize] (or anywhere else... IIRC it's also done in NSUserDefaults) is a good idea. Just to recap, +[NSObject initialize] does setlocale(LC_ALL, ); which reads the current locale from the LANG environment variable (and others)[1] and sets all of the libc locale settings to that locale - so after +[NSObject initiazlize], printf(%g, 1.23) will output 1,23 if your system locale is French
Re: setlocale() [Was: Re: NSNumberFormater test fails]
Hi, I just had a look in to this problem. While it sounds like there is certainly a bug in libicu - it should not break if the libc locale is changed - I am very skeptical that setting the libc locale as we do in +[NSObject initialize] (or anywhere else... IIRC it's also done in NSUserDefaults) is a good idea. Just to recap, +[NSObject initialize] does setlocale(LC_ALL, ); which reads the current locale from the LANG environment variable (and others)[1] and sets all of the libc locale settings to that locale - so after +[NSObject initiazlize], printf(%g, 1.23) will output 1,23 if your system locale is French, for example. My main problem with this is, I don't think any shared library really has the right to change this setting… if an application/tool wanted to switch from the default C locale to the current system locale, that should be the application's decision, since it has global consequences for everything running in that process (changing the semantics of printf!). But there would hardly be a point to doing that because GNUstep provides more powerful formatting anyway (NSNumberFormatter, etc.) The official way of setting the locale in ICU is using uloc_setDefault() According to the ICU docs, the notion of locale in ICU is totally independent of libc's. For number formatting, the ICU default locale only has an effect if you pass NULL for the locale when calling unum_open. So setting the libc locale should have no effect on ICU's default locale (not true because of the bug mentioned below), and vice-versa - setting the ICU locale has no effect on the system locale. Eric [1] actually more complicated, at least for glibc: http://www.gnu.org/software/libc/manual/html_mono/libc.html#Locale-Categories On 2012-01-23, at 6:43 AM, Stefan Bidi wrote: On Mon, Jan 23, 2012 at 3:01 AM, Fred Kiefer fredkie...@gmx.de wrote: That bug description is not accurate. When running the NSNumberformatter test program we only call setlocale() twice, once with and once with NULL as the locale. That would be supported behaviour according to the bug description, but clearly it is not. I'll attach that modified version to the bug report. I changed your test program to call setlocale() and now it also reports NaN (See attachment). This really makes me wonder whether it is such a great idea to use an internationalisation library that only supports English :-( In all fairness, it has been classified as bug in the library. The official way of setting the locale in ICU is using uloc_setDefault(). To get the locale it's uloc_getDefault(). But I see your point and am a little surprised that this is even an issue. I'm even more surprised that it keeps getting pushed off to a later release. It seems to have originally been scheduled for 4.6, then 4.8 and now 5.0. BTW: Is there a reason why the macro STRING_FROM_NUMBER calls the conversion twice, even when it was successful on the first attempt? I don't like the use of macros that much it really makes it hard to tell what is going on and code in macros never gets as much review as normal code. No, it's wrong. I saw that when mucking around in there, too, but didn't a fix commit (I'll do so when I get home, today). Don't ask me how I managed to screw that up... I don't know either. On 21.01.2012 23:00, Stefan Bidi wrote: After running a few more tests and still not understanding what is going on I went to good and found this bug report: http://bugs.icu-project.org/trac/ticket/8214 Seems that ICU does not like it when we use setlocale(). On Sat, Jan 21, 2012 at 1:53 PM, Stefan Bidistefanb...@gmail.com wrote: I am completely baffled by this bug. I've been trying to debug this for the last 3 hrs and have gotten absolutely no where. I added a unum_open and unum_formatDouble call in -init and I still get NaN when LANG=de_DE.UTF-8. The test program continues to work without a hitch, though. Something about how we handle the NSNumberFormatterInternal structure is screwing up UNumberFormat (I also added a unum_open and unum_formatDouble call in basic10_4.m and it worked fine). On Sat, Jan 21, 2012 at 11:00 AM, Stefan Bidistefanb...@gmail.comwrote: On Sat, Jan 21, 2012 at 10:41 AM, Fred Kieferfredkie...@gmx.de wrote: Your test code works fine here and results in 1.234 as expected. My $LANG is de_DE.UTF-8. And with $LANG set to C the test run fine. Strange enough currentLocale ends up being en_US_POSIX -currentLocale looks for a Locale default, if it exists that's what it uses. Do you have that set? This still wouldn't explain why UNumberFormat is returning NaN. Both you and Philippe have a valid locale. On the plus side, if I set LANG=de_DE.UTF-8 I can reproduce this. I'll go try to figure out what's going on. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: more icon in toolbars
On 2012-02-01, at 2:29 PM, Riccardo Mottola wrote: Hi, See bug report #35379. I waited a few days for somebody with more graphical skills to address this issue, but as nobody showed up, I did the best I could, which definitely wasn't enough. You will have to live with this horrible image until after the next release. Or replace it with something proper. As for up to a couple of days, this image was broken for half a year and nobody noticed... Hmm, perhaps the higher resolution layer is confusing? I can't even open it properly in gimp. I know, multi-image TIFF's are a pain to deal with. Maybe after the release I should add support for loading images with an @2x suffix like cocoa added in 10.7, and split apart all of the high-res artwork I added. I looked at both layers, they look decent. However when opening Flexisheet, which has most toolbars clipping the result is really terrible. SO it is not the artwork itself, but somehow how it is used. could you post a screenshot? I don't have flexisheet handy. Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cursor issues in gworkspace
I run in to the same type of problem frequently as well (cursor gets stuck on the wrong image). I created a bug to track this problem: https://savannah.gnu.org/bugs/?35431 Hopefully it's something we can fix in the next development period… On 2012-02-01, at 1:38 PM, Riccardo Mottola wrote: Hi, On 02/01/2012 09:51 AM, Sebastian Reitenbach wrote: Hi, I recognized some issuws with the mouse cursor in GWorkspace. I have everything from svn, base/gui/back (cairo), gworkspace, and libobjc2-1.6 release. I recognized, when I drag n drop an application to the dock on the right, then the mouse cursor becomes green, when its allowed to drop the file on the dock. So far so good, but after dropping the app in the dock, the cursor stays green sadly, this is not a new issue. It is most evident with GWorkspace, but happens also with other cursor changes, even if less frequently. So, as ugly as it is, it is not a new bug and I would not consider it a blocker. Riccardo ___ 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: GNUstep Code Freeze
Hi Fred, I forgot about the ImageMagick/ghostscript image reps - IIRC we agreed to disable them for this release? I just did so. GSGhostscriptImageRep is removed from the build, but ImageMagick is just disabled by default in the configure script. Eric On 2012-01-29, at 2:49 PM, Fred Kiefer wrote: I would like to collect some feedback on the current state. Are there any bugs still open that would block making a release? That would be really serious bugs that stop a critical GNUstep application from working, definitely worked in the last release and cannot be worked around in some way. As for the ICU locale issue we have the work around to not use ICU for people with other languages, that should give them about the fallback that they had in previous base releases. As for the gui bugs, I am under the impression that we wont be able so fix much more for this release. But a lot of testing is still going on. Adam, are you willing to prepare this release again? Fred On 20.01.2012 00:27, Fred Kiefer wrote: In order to get a full GNUstep release out before FOSDEM, that is at least base/gui/back, maybe also make, Richard, Eric and I have decided to put a code freeze for these libraries in place. Only strict bug fixes should go into the code over the next week (or maybe a bit longer) and everybody should try to find time to test the current code on as many different machines as possible. There hasn't been a gui release in almost a year and now seems as good a time as ever. Feel free to report any bugs you find on the mailing list or even better in the bug tracker on Savannah. ___ 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: GNUstep Code Freeze
I can't reproduce this; could you post gdb backtraces please? On 2012-01-29, at 3:46 PM, Riccardo Mottola wrote: Hi, Germán Arias wrote: I don't know if the problem that Riccardo reported is a critical bug or not. If the user change the theme at panel Themes, the app crash. This happen with all apps. actually, I can't even open the theme panel, so I don't change the theme. I try to :) Riccardo ___ 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: GNUstep Code Freeze
Hey Greg, Not sure if this is what you're referring to, but I made a change in december (r34320) that broke editing of table views in gorm for a while, such as editing outlet names. 2011-12-18 Eric Wasylishen ewasylis...@gmail.com * Source/NSTableView.m (-_isCellEditableColumn:row:): Tweak criteria for determining cell editability:: - the delegate (if present) must say YES - and the cell itself must return YES for isEditable - and the table column must return YES for isEditable Previously you could edit cells that returned NO for isEditable if the column they were in was editable. However, later I made two fixes in gorm which should have fixed the problem: r34552 | ericwa | 2012-01-15 14:52:43 -0700 (Dim, 15 jan 2012) | 4 lines * English.lproj/GormClassInspector.gorm: Re-save with the last change, so the outlet/action table data cells are editable. r34551 | ericwa | 2012-01-15 14:46:00 -0700 (Dim, 15 jan 2012) | 5 lines * Palettes/3Containers/GormTableColumnAttributesInspector.m: Set editable state of the data cell to match editable state of the column. (NSTableView now refuses to edit non-editable data cells in editable columns.) Are you still running in to this problem, or is it something different? I just checked now and I can edit outlet/action names. Eric On 2012-01-29, at 17:27, Gregory Casamento wrote: Fred, I need to determine if the current issue with changing outlet names in Gorm is due to an AppKit issue or a Gorm issue. This shouldn't take long. I'll report back shortly. GC On Sun, Jan 29, 2012 at 4:49 PM, Fred Kiefer fredkie...@gmx.de wrote: I would like to collect some feedback on the current state. Are there any bugs still open that would block making a release? That would be really serious bugs that stop a critical GNUstep application from working, definitely worked in the last release and cannot be worked around in some way. As for the ICU locale issue we have the work around to not use ICU for people with other languages, that should give them about the fallback that they had in previous base releases. As for the gui bugs, I am under the impression that we wont be able so fix much more for this release. But a lot of testing is still going on. Adam, are you willing to prepare this release again? Fred On 20.01.2012 00:27, Fred Kiefer wrote: In order to get a full GNUstep release out before FOSDEM, that is at least base/gui/back, maybe also make, Richard, Eric and I have decided to put a code freeze for these libraries in place. Only strict bug fixes should go into the code over the next week (or maybe a bit longer) and everybody should try to find time to test the current code on as many different machines as possible. There hasn't been a gui release in almost a year and now seems as good a time as ever. Feel free to report any bugs you find on the mailing list or even better in the bug tracker on Savannah. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev -- Gregory Casamento Open Logic Corporation, Principal Consultant yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) http://www.gnustep.org http://heronsperch.blogspot.com ___ 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: OpenGL context without AppKit
Hi Ivan, One idea I've thought of is turning the display server part of -back in to a standalone framework that doesn't depend on gui, then making gui depend on this new display server framework + opal. I think it would be relatively straightforward. This would let you use the display server without depending on -gui, and make the display server easier to test in isolation (one of my complaints with the current -back is that it is hard to test; it's only tested indirectly through gui.) Eric On 2012-01-28, at 5:38 AM, Ivan Vučica wrote: Hi, I've began working on CARenderer for quartzcore. Since I'm trying to avoid depending on -gui, and since -back depends on -gui, I have no way to replace the following function: + (CARenderer *)rendererWithCGLContext:(void *)ctx options:(NSDictionary *)dict The reason for avoiding depending on -gui in quartzcore is, naturally, UIKit. Any chance that this is enabled in the nearby future? Without that I'll probably just add extra method to pass GLX context, since the little amount of platform-specific code in UIKit will probably initially be working solely with GLX (considering that, again, I can't use -back without -gui). To start development, I'll use NSOpenGLContext instance as the first argument, however that's far from ideal. On a side note, should quartzcore perhaps be renamed? I feel that name such as coreanimation is not implying OS X as much as quartzcore. -- Ivan Vučica - i...@vucica.net ___ 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: Dialog display problem (Re: GNUstep Code Freeze)
Hi Philippe, I just got a new ubuntu 11.10 install set up natively instead of in a VM, so I can actually use Unity now. :-) I can reproduce this... unfortunately GS is almost unusable in Unity - menus often don't appear in the correct place, the menu selection doesn't always follow your mouse, etc. Hopefully, these are things we can fix at some point. Eric On 2012-01-24, at 3:20 PM, Philippe Roussel wrote: Le mardi 24 janvier 2012 à 12:32 -0700, Eric Wasylishen a écrit : Hm.. Are those gaps temporary, or does the window stay like that? Unfortunately. it's probably something difficult to fix which will have to wait for the release after this one. Resizing the window generally fixes it but it also happens with non resizeable panels. Philippe ___ 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: Ugly flickering in some views
Hi Fred, Ok, thanks for testing. I'm not sure what we should do; I asked Fred's opinion. If we end up keeping copy-on-scroll on for the release you can put in this hack for the problematic scroll view: [[aScrollView contentView] setCopiesOnScroll: NO]; Not ideal, but debugging flickering problems tends to be very difficult. German's problem was before you applied r34614, how did that change affect this problem? But that patch seems to have its own problems. My main problem is when resizing a whole window, this flickers horribly, but I am not sure whether GNUstep is causing this or my driver for the graphic card. But it happens only with GNUstep windows. What are our options here? - Find a proper solution within the next few days. - Disable copy-on-scroll in all scroll views. - Revert to the old cairo surface. - Ignore the problem as it only happens for some views. None of that (apart from the first one, which isn't that realistic) sounds too attractive. Disabling copy-on-scroll will make scroll views horribly slow and affect everybody, even people not using cairo. I think I hate the option to revert the standard cairo surface the least. This should send us back to the way GNUstep was about a year ago, but we can revert this step if we find a proper fix for the open issues. Fred I thought a bit about this. First, sorry for putting us in this situation! The conclusion I came to is I should have strictly followed the code freeze. Only bugfixes that have a localized effect should be allowed in during the freeze… we should be shipping code that was tested over the last 8 months and not doing large last-minute changes like I did. So my preference is to revert the two commits to gui I made since the freeze (r34606 and r34614). This is, in other words, the Disable copy-on-scroll in all scroll views. option. I know scrolling will be slower than it should, but on the other hand it took almost 8 months to realize I had introduced a bug that was disabling it, and AFAIK no one complained to the mailing list. If I find solution to the scrolling flickering (or the general window resize flickering) in the next few weeks after the release, we could always do a bugfix release. btw, but is it KDE4 where you are having very bad flickering when resizing? Which video card do you have? Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Ugly flickering in some views
On 2012-01-25, at 12:21 PM, Fred Kiefer wrote: Hi Eric, On 25.01.2012 20:02, Eric Wasylishen wrote: Ok, thanks for testing. I'm not sure what we should do; I asked Fred's opinion. If we end up keeping copy-on-scroll on for the release you can put in this hack for the problematic scroll view: [[aScrollView contentView] setCopiesOnScroll: NO]; Not ideal, but debugging flickering problems tends to be very difficult. German's problem was before you applied r34614, how did that change affect this problem? But that patch seems to have its own problems. My main problem is when resizing a whole window, this flickers horribly, but I am not sure whether GNUstep is causing this or my driver for the graphic card. But it happens only with GNUstep windows. What are our options here? - Find a proper solution within the next few days. - Disable copy-on-scroll in all scroll views. - Revert to the old cairo surface. - Ignore the problem as it only happens for some views. None of that (apart from the first one, which isn't that realistic) sounds too attractive. Disabling copy-on-scroll will make scroll views horribly slow and affect everybody, even people not using cairo. I think I hate the option to revert the standard cairo surface the least. This should send us back to the way GNUstep was about a year ago, but we can revert this step if we find a proper fix for the open issues. Fred I thought a bit about this. First, sorry for putting us in this situation! The conclusion I came to is I should have strictly followed the code freeze. Only bugfixes that have a localized effect should be allowed in during the freeze… we should be shipping code that was tested over the last 8 months and not doing large last-minute changes like I did. So my preference is to revert the two commits to gui I made since the freeze (r34606 and r34614). This is, in other words, the Disable copy-on-scroll in all scroll views. option. I know scrolling will be slower than it should, but on the other hand it took almost 8 months to realize I had introduced a bug that was disabling it, and AFAIK no one complained to the mailing list. If I find solution to the scrolling flickering (or the general window resize flickering) in the next few weeks after the release, we could always do a bugfix release. Wouldn't it be simpler to just turn off copy on scroll in the NSScrollView? Do you mean instead of reverting r34606, just turn off copy on scroll in NSScrollView? I guess that should be safe. I think r34614 should be reverted until after the release, though. btw, but is it KDE4 where you are having very bad flickering when resizing? Which video card do you have? It is KDE4 and I am using a AMD graphics card. Maybe I should play a bit with the configuration program. Fred Ok, thanks for the info. I have a nvidia 9400m, and just did a native install of Ubunutu on my laptop (was using VirtualBox before) - so I'll try kde4 too. Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: QuartzCore and Opal
Hi Ivan, I've also tried to compile Opal. I'm running into issues when it tries to include CoreFoundation/CFStream.h which does not ship with corebase. Any tips on that one? I presume Opal does run solely with GNUstep-provided libraries? I got opal and the examples to run on Jan 2 - try r34396. When I was working on it the dependencies listed in README were accurate; now Amr has added a dependency on corebase. I'm not sure what Amr is planning to do with opal. I don't have a plan for it either, but I would like to see gnustep-gui use it. Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gui patch for review: -[NSView setBounds*:] - remove setNeedsDisplay: YES calls
I investigated this and committed a fix for scrolling in a zoomed TextEdit document yesterday because the fix was quite simple (r34614). On 2012-01-23, at 4:05 PM, Eric Wasylishen wrote: I just found a bug caused by re-enabling copy-on-scroll. Open TextEdit (https://github.com/ericwa/TextEdit), open a document or paste in some text, Choose Format-Wrap to Page, set the zoom to 150%, and scroll horizontally, slowly. You'll see horizontal blurring. Seems that the regions being copied aren't pixel-aligned. Should we just disable copy-on-scroll for this release? Ship with this bug? Try using -centerScanRect in -[NSView scrollRect: (NSRect)aRect by: (NSSize)delta]? I just fear trying to fix it now will create more bugs at the last minute... Eric On 2012-01-20, at 11:54 PM, Eric Wasylishen wrote: Hi, This patch reverts part of r32955 which I committed last april but I now see was a mistake, and I just discovered is breaking the copy-on-scroll behaviour of NSClipView - we end up always redrawing the entire visible portion of the document view right now. In r32955 I added [self setNeedsDisplay: YES] calls to -[NSView setBounds:], -setBoundsOrigin:, and -setBoundsSize:, even though these are documented explicitly as not marking the view for needing display. (With r32955 I was trying to fix a bug in TextEdit, which calls setBoundsSize: on NSClipView when you change the page zoom, and expects the view to mark itself as needing display. This is actually a bug in TextEdit - it should mark the clip view as needing redisplay itself.) -Eric NSViewBoundsRemoveSetNeedsDisplay.diff ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gui patch for review: -[NSView setBounds*:] - remove setNeedsDisplay: YES calls
Ugh, r34614 introduced more bugs itself (resizing the panes in Grr can make the table headers change size). I should know this would happen if I tried to change things during a code freeze... Fred, do you think we should just ship the release with copy-on-scroll disabled? That would fix the flickering in FisicaLab reported by German, and the blurring I reported here in zoomed TextEdit. We could turn it back on after the release and try to fix those bugs. Eric On 2012-01-24, at 11:05 AM, Eric Wasylishen wrote: I investigated this and committed a fix for scrolling in a zoomed TextEdit document yesterday because the fix was quite simple (r34614). On 2012-01-23, at 4:05 PM, Eric Wasylishen wrote: I just found a bug caused by re-enabling copy-on-scroll. Open TextEdit (https://github.com/ericwa/TextEdit), open a document or paste in some text, Choose Format-Wrap to Page, set the zoom to 150%, and scroll horizontally, slowly. You'll see horizontal blurring. Seems that the regions being copied aren't pixel-aligned. Should we just disable copy-on-scroll for this release? Ship with this bug? Try using -centerScanRect in -[NSView scrollRect: (NSRect)aRect by: (NSSize)delta]? I just fear trying to fix it now will create more bugs at the last minute... Eric On 2012-01-20, at 11:54 PM, Eric Wasylishen wrote: Hi, This patch reverts part of r32955 which I committed last april but I now see was a mistake, and I just discovered is breaking the copy-on-scroll behaviour of NSClipView - we end up always redrawing the entire visible portion of the document view right now. In r32955 I added [self setNeedsDisplay: YES] calls to -[NSView setBounds:], -setBoundsOrigin:, and -setBoundsSize:, even though these are documented explicitly as not marking the view for needing display. (With r32955 I was trying to fix a bug in TextEdit, which calls setBoundsSize: on NSClipView when you change the page zoom, and expects the view to mark itself as needing display. This is actually a bug in TextEdit - it should mark the clip view as needing redisplay itself.) -Eric NSViewBoundsRemoveSetNeedsDisplay.diff ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Ugly flickering in some views
Hi Germán, On 2012-01-23, at 11:15 PM, Germán Arias wrote: On 2012-01-23 21:16:01 -0600 Eric Wasylishen ewasylis...@gmail.com wrote: Thanks for the info.. this is bad because it sounds like the NSCopyBits is causing flickering. I have another debugging request: -update gui/back again -verify the flickering is back. -open back/Source/cairo/CairoContext.m and change this section: //#define _CAIRO_SURFACE_CLASSNAME XGCairoSurface //#include cairo/XGCairoSurface.h //#define _CAIRO_SURFACE_CLASSNAME XGCairoXImageSurface //#include cairo/XGCairoXImageSurface.h #define _CAIRO_SURFACE_CLASSNAME XGCairoModernSurface #include cairo/XGCairoModernSurface.h to this: //#define _CAIRO_SURFACE_CLASSNAME XGCairoSurface //#include cairo/XGCairoSurface.h #define _CAIRO_SURFACE_CLASSNAME XGCairoXImageSurface #include cairo/XGCairoXImageSurface.h //#define _CAIRO_SURFACE_CLASSNAME XGCairoModernSurface //#include cairo/XGCairoModernSurface.h -make and install back, and try fisicalab again. This change solves the problem. I'm assuing you're using the cairo backend. I'm curious if changing from XGCairoModernSurface to XGCairoXImageSurface will fix the problem. Also it might be worth trying art or xlib, and see if you still get the same flickering. Yes, I'm using cairo. And with xlib and art all works fine. The problem is only with cairo. I don't understand this problem. But, for example, the fisicalab's chalkboard works fine. Even when is basically the same. An NSView with a lot of buttons that can display images. The only difference is that its content isn't copied from another window. And why this problem occurs only when I move the scrollbar to down? Thanks. Ok, thanks for testing. I'm not sure what we should do; I asked Fred's opinion. If we end up keeping copy-on-scroll on for the release you can put in this hack for the problematic scroll view: [[aScrollView contentView] setCopiesOnScroll: NO]; Not ideal, but debugging flickering problems tends to be very difficult. -Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Dialog display problem (Re: GNUstep Code Freeze)
Hm.. Are those gaps temporary, or does the window stay like that? Unfortunately. it's probably something difficult to fix which will have to wait for the release after this one. Eric On 2012-01-24, at 10:31 AM, Philippe Roussel wrote: Le vendredi 20 janvier 2012 à 00:27 +0100, Fred Kiefer a écrit : In order to get a full GNUstep release out before FOSDEM, that is at least base/gui/back, maybe also make, Richard, Eric and I have decided to put a code freeze for these libraries in place. Only strict bug fixes should go into the code over the next week (or maybe a bit longer) and everybody should try to find time to test the current code on as many different machines as possible. Resizing the NSSavePanel I can easily obtain something like the attached screenshots. I'm running ubuntu with Unity, maybe that's related. Philippe display-bug-down.pngdisplay-bug-up.png___ 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: GNUstep Code Freeze
I just tested the last release (2011-04-14) of base/gui/back, and it looks like the text overlapping does not occur there. My test case is pasting a paragraph of text into Ink and setting the font to DejaVu Sans. I'll try bisecting to find the revision that introduced the bug, and maybe it will be a quick fix. Eric On 2012-01-23, at 3:10 AM, Sebastian Reitenbach wrote: Fred Kiefer fredkie...@gmx.de wrote: In order to get a full GNUstep release out before FOSDEM, that is at least base/gui/back, maybe also make, Richard, Eric and I have decided to put a code freeze for these libraries in place. Only strict bug fixes should go into the code over the next week (or maybe a bit longer) and everybody should try to find time to test the current code on as many different machines as possible. There hasn't been a gui release in almost a year and now seems as good a time as ever. Feel free to report any bugs you find on the mailing list or even better in the bug tracker on Savannah. I hope this strange font drawing problem I've seen, and also Riccardo and Philippe have seen will also get fixed? Sebastian Fred ___ 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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep Code Freeze
I actually narrowed it down and have a fix coming soon. This started when we switched to the modern cairo surface I wrote. The bug is in the way CairoFontInfo.m doesn't deal with the hinting settings of cairo_font_info_t. Basically, it creates a default font options object and uses that to make measurements of the glyphs. But, when it comes time to draw text with that font on a xlib surface, which defaults to having hinting enabled, cairo draws with hinting - so we have metrics calculated with no hinting, but drawing with hinting, and get the resulting mess. Eric On 2012-01-23, at 1:55 PM, Fred Kiefer wrote: I would start with checking the screen resolution code as this seems to only affect monitors with strange geometry. Sebastian, could you try to re-enable the old code in the method resolutionForScreen: (XGServerWindow.m) and see whether this make any difference? Could you also report the result of the command xdpyinfo | grep -B2 resolution on a monitor where this problem exists? Fred On 23.01.2012 20:33, Eric Wasylishen wrote: I just tested the last release (2011-04-14) of base/gui/back, and it looks like the text overlapping does not occur there. My test case is pasting a paragraph of text into Ink and setting the font to DejaVu Sans. I'll try bisecting to find the revision that introduced the bug, and maybe it will be a quick fix. Eric On 2012-01-23, at 3:10 AM, Sebastian Reitenbach wrote: Fred Kieferfredkie...@gmx.de wrote: In order to get a full GNUstep release out before FOSDEM, that is at least base/gui/back, maybe also make, Richard, Eric and I have decided to put a code freeze for these libraries in place. Only strict bug fixes should go into the code over the next week (or maybe a bit longer) and everybody should try to find time to test the current code on as many different machines as possible. There hasn't been a gui release in almost a year and now seems as good a time as ever. Feel free to report any bugs you find on the mailing list or even better in the bug tracker on Savannah. I hope this strange font drawing problem I've seen, and also Riccardo and Philippe have seen will also get fixed? ___ 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: GNUstep Code Freeze
I committed a fix. Please test both on-screen display, and the result of saving a PDF from Ink (print dialog-save button-foo.pdf). Both work for me with the font that was previously causing problems (DejaVu Sans - probably many others too). Eric On 2012-01-23, at 2:24 PM, Eric Wasylishen wrote: I actually narrowed it down and have a fix coming soon. This started when we switched to the modern cairo surface I wrote. The bug is in the way CairoFontInfo.m doesn't deal with the hinting settings of cairo_font_info_t. Basically, it creates a default font options object and uses that to make measurements of the glyphs. But, when it comes time to draw text with that font on a xlib surface, which defaults to having hinting enabled, cairo draws with hinting - so we have metrics calculated with no hinting, but drawing with hinting, and get the resulting mess. Eric On 2012-01-23, at 1:55 PM, Fred Kiefer wrote: I would start with checking the screen resolution code as this seems to only affect monitors with strange geometry. Sebastian, could you try to re-enable the old code in the method resolutionForScreen: (XGServerWindow.m) and see whether this make any difference? Could you also report the result of the command xdpyinfo | grep -B2 resolution on a monitor where this problem exists? Fred On 23.01.2012 20:33, Eric Wasylishen wrote: I just tested the last release (2011-04-14) of base/gui/back, and it looks like the text overlapping does not occur there. My test case is pasting a paragraph of text into Ink and setting the font to DejaVu Sans. I'll try bisecting to find the revision that introduced the bug, and maybe it will be a quick fix. Eric On 2012-01-23, at 3:10 AM, Sebastian Reitenbach wrote: Fred Kieferfredkie...@gmx.de wrote: In order to get a full GNUstep release out before FOSDEM, that is at least base/gui/back, maybe also make, Richard, Eric and I have decided to put a code freeze for these libraries in place. Only strict bug fixes should go into the code over the next week (or maybe a bit longer) and everybody should try to find time to test the current code on as many different machines as possible. There hasn't been a gui release in almost a year and now seems as good a time as ever. Feel free to report any bugs you find on the mailing list or even better in the bug tracker on Savannah. I hope this strange font drawing problem I've seen, and also Riccardo and Philippe have seen will also get fixed? ___ 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: gui patch for review: -[NSView setBounds*:] - remove setNeedsDisplay: YES calls
I just found a bug caused by re-enabling copy-on-scroll. Open TextEdit (https://github.com/ericwa/TextEdit), open a document or paste in some text, Choose Format-Wrap to Page, set the zoom to 150%, and scroll horizontally, slowly. You'll see horizontal blurring. Seems that the regions being copied aren't pixel-aligned. Should we just disable copy-on-scroll for this release? Ship with this bug? Try using -centerScanRect in -[NSView scrollRect: (NSRect)aRect by: (NSSize)delta]? I just fear trying to fix it now will create more bugs at the last minute... Eric On 2012-01-20, at 11:54 PM, Eric Wasylishen wrote: Hi, This patch reverts part of r32955 which I committed last april but I now see was a mistake, and I just discovered is breaking the copy-on-scroll behaviour of NSClipView - we end up always redrawing the entire visible portion of the document view right now. In r32955 I added [self setNeedsDisplay: YES] calls to -[NSView setBounds:], -setBoundsOrigin:, and -setBoundsSize:, even though these are documented explicitly as not marking the view for needing display. (With r32955 I was trying to fix a bug in TextEdit, which calls setBoundsSize: on NSClipView when you change the page zoom, and expects the view to mark itself as needing display. This is actually a bug in TextEdit - it should mark the clip view as needing redisplay itself.) -Eric NSViewBoundsRemoveSetNeedsDisplay.diff ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Ugly flickering in some views
It could be cause by gui r34606 because that re-enabled copy-on-scroll which had been accidentally turned off for several months. See if the problem goes away if you update gui to r34605 Eric On 2012-01-23, at 4:30 PM, Germán Arias wrote: I have a problem with FisicaLab in SVN (I can't reproduce this problem with other application). In the elements for static of rigid bodies, that are inside a scrollview, when I use the mouse wheel to navigate all is OK. But if I use the scrollbar or the arrows, when I move to down, the view show an ugly flickering. The content of this view is a copy of the content of a window (staticRigidBodies.gorm file). This worked fine previously. So, I don't understand where is the problem here. Thanks. ___ 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: Ugly flickering in some views
Thanks for the info.. this is bad because it sounds like the NSCopyBits is causing flickering. I have another debugging request: -update gui/back again -verify the flickering is back. -open back/Source/cairo/CairoContext.m and change this section: //#define _CAIRO_SURFACE_CLASSNAME XGCairoSurface //#include cairo/XGCairoSurface.h //#define _CAIRO_SURFACE_CLASSNAME XGCairoXImageSurface //#include cairo/XGCairoXImageSurface.h #define _CAIRO_SURFACE_CLASSNAME XGCairoModernSurface #include cairo/XGCairoModernSurface.h to this: //#define _CAIRO_SURFACE_CLASSNAME XGCairoSurface //#include cairo/XGCairoSurface.h #define _CAIRO_SURFACE_CLASSNAME XGCairoXImageSurface #include cairo/XGCairoXImageSurface.h //#define _CAIRO_SURFACE_CLASSNAME XGCairoModernSurface //#include cairo/XGCairoModernSurface.h -make and install back, and try fisicalab again. I'm assuing you're using the cairo backend. I'm curious if changing from XGCairoModernSurface to XGCairoXImageSurface will fix the problem. Also it might be worth trying art or xlib, and see if you still get the same flickering. Thanks Eric On 2012-01-23, at 5:46 PM, Germán Arias wrote: With r34605 all works fine. On 2012-01-23 17:56:35 -0600 Eric Wasylishen ewasylis...@gmail.com wrote: It could be cause by gui r34606 because that re-enabled copy-on-scroll which had been accidentally turned off for several months. See if the problem goes away if you update gui to r34605 Eric On 2012-01-23, at 4:30 PM, Germán Arias wrote: I have a problem with FisicaLab in SVN (I can't reproduce this problem with other application). In the elements for static of rigid bodies, that are inside a scrollview, when I use the mouse wheel to navigate all is OK. But if I use the scrollbar or the arrows, whe n I move to down, the view show an ugly flickering. The content of this view is a copy of the content of a window (staticRigidBodies.gorm file). This worked fine previously. So, I don't understand where is the problem here. Thanks. ___ 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
gui patch for review: -[NSView setBounds*:] - remove setNeedsDisplay: YES calls
Hi,This patch reverts part of r32955which I committed last april but I now see was a mistake, andI just discovered is breaking the copy-on-scroll behaviour of NSClipView - we end up always redrawing the entire visible portion of the document view right now.Inr32955I added [self setNeedsDisplay: YES] calls to -[NSView setBounds:], -setBoundsOrigin:, and -setBoundsSize:, even though these are documented explicitly as not marking the view for needing display.(Withr32955Iwas trying to fix a bug in TextEdit, which calls setBoundsSize: on NSClipView when you change the page zoom, and expects the view to mark itself as needing display. This is actually a bug in TextEdit - it should mark the clip view as needing redisplay itself.)-Eric NSViewBoundsRemoveSetNeedsDisplay.diff Description: Binary data ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Vespucci doesn't show images anymore
The code is now at svn+ssh://svn.gna.org/svn/gnustep/libs/gui/branches/ericwa-text On 2012-01-19, at 11:43 AM, Eric Wasylishen wrote: Oh, sorry - I don't think that patch displays text attachments. I continued work on that patch a bit; here is the latest version. It still needs a lot of work before it's ready to be committed. This version has an efficient loop for drawing runs of glyphs, but I may have introduced a bug because the insertion point position seems wrong. Text attachments aren't drawn yet, either. To fully make sense the patch should really accompany an update of the backend font code to use real glyphs and respect the advances given in GSShowGlyphsWithAdvances. I guess I should put this in a SVN branch rather than emailing patches around… :-) text9.diff Eric On 2012-01-19, at 5:18 AM, Sebastian Reitenbach wrote: I found the problem ;) Its Erics patch he sent to mitigate the problem of the squeezed fonts displaying (see the thread: fonts displaying strangely). Compiling -gui without that patch, then Vespucci shows me the images. So not sure whether this is a bug in -gui or swk, since I haven't seen any other problems in other applications yet. So now for the FOSDEM I have two options: * either have no images in Vespucci * or squeezed fonts in nearly any application Since the font problem shows up for me on the notebook I wanted to use for the FOSDEM. Preferably I'd like to have both, images in Vespucci, and non-squeezed fonts ;) cheers, Sebastian On Wednesday, January 18, 2012 11:13 CET, Sebastian Reitenbach sebas...@l00-bugdead-prods.de wrote: On Monday, January 16, 2012 16:50 CET, Sebastian Reitenbach sebas...@l00-bugdead-prods.de wrote: On Monday, January 16, 2012 16:02 CET, Fred Kiefer fredkie...@gmx.de wrote: On 15.01.2012 14:27, Sebastian Reitenbach wrote: I use gnustep -base, -gui (linked against ImageMagick), -back (cairo) from svn. (not yet the latest changes that went in with regard to the images loading speedup). I use simplewebkit from svn, and Vespucci from GAP CVS. I'm on OpenBSD i386 -current, gcc-4.2.1 with gcc libobjc. Riccardo told me that it used to work for him in December, the last time I checked is lng ago, but I remember it used to work for me too. Could you please provide a bit more details here? both swk and vespucci seem to compile fine, Also when I start Vespucci, and open a web page, there is no warning about problems with images. (threre is actually a lot output from swk, but nothing that looks serious) Are you on a 64 bit machine? Then the most likely reason for the problem is that SWK and Vespucci have not been updated for the change in base. All variable that may contain a value of NSNotFound should be changed to NSUInteger. I'm on OpenBSD i386 as stated above, so 32 Bit. I'd call it amd64 for x86_64 ;) I did some more tests, on the same machine: updated -base, -gui, -back from svn, yesterday afternoon. - no change then tried with libobjc2 (previous tests all with libojc from gcc-4.2.1) - no change then tried different backends (previously with cairo, then with xlib and art backend) - no change - with the xlib backend (tested over ssh -Y like the others), the Vespucci main window stayed empty, not even text shown, the other two backends at least showed the text. If someone else has suggestions what could be my problem here, and what else to test, please let me know. Sebastian Sebastian Hope this helps Fred ___ Discuss-gnustep mailing list discuss-gnus...@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list discuss-gnus...@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list discuss-gnus...@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: X11 scroll-wheel improvements
Hi Fred,
On 2012-01-16, at 3:29 AM, Fred Kiefer wrote:
On 16.01.2012 09:43, Eric Wasylishen wrote:
Hey, I just made two commits to gnustep-back (r34553 and r34554)
which make a big improvement to scrolling with a mouse scrollwheel or
trackpad's scrolling feature.
The first helps avoid the GSDisplayServer event queue from filling up
which prevents window autodisplay, and the second implements
coalescing for scroll events. The coalescing seems to work very
nicely - it means that the rate of scroll events sent to gui depends
on how quickly gui can deal with them. As a result, scrolling with
the scroll wheel feels just about as responsive as grabbing and
moving the scroll bar.
Let me know if it also works well for you, or you have any problems.
:-)
I definitely like the coalescing of scroll events (although this might mess
up the order of events, was that intended?), but am unsure about the other
change.
You're right, that is a mistake and I should only be reading events from the
head of the queue.
If we should not listen for events in NSConnectionReplyMode, we need a
similar change for the Windows backend as well. But wont this lead to an
application that might be unable to participate in a DragDrop interaction?
Or anything else that requires a mixture of X events and DO?
I'm not sure… I don't have a great understanding of run loops. It doesn't seem
to have broken drag drop.
My understanding is that NSConnectionReplyMode is a run loop mode only used for
private run loops created by NSConnection for synchronous method calls. If that
is a correct interpretation than I think not listening for X events in
NSConnectionReplyMode makes sense.
In you checkin comment you state In the long run I think we should get rid
of the AppKit event queue. What benefit do we get from only getting one
event at a time from the X event queue?
The problem is, the run loop doesn't run until the GSDisplayServer queue is
empty (see -[GSDisplayServer getEventMatchingMask:…]) so you end up with bugs
like prior to r34553, you can prevent the Ink window from autodisplaying by
continuously rotating the scroll wheel.
In other words, if there are 3 events in the GSDisplayServer queue, the main
loop in -[NSApplication run] will run for 3 iterations without running the
NSRunLoop, and hence no performers fire, and window autodisplay won't happen.
This was the motivation r34553, it only adds one event at a time to the
GSDisplayServer queue.
For visualizing the queue size you can add this:
if ([event_queue count] 1)
{
NSLog(@--queue has 1 ( %d ) objects. last: %@, (int)[event_queue
count], [event_queue objectAtIndex: [event_queue count] - 1]);
}
to the start of the do/while loop in -[GSDisplayServer getEventMatchingMask:…].
We would also loose the ability to post events into the queue from code. Or
would you want to generate an X event from the NSEvent and put that in the X
queue?
A separate queue allows us to generate multiple events from one X event, or
as seen in your scrollwheel code, to compress events.
I think that these changes are wrong and that we rather should try to find
out how to better manage our event queue to get the benefits from it.
Well, maybe the suggestion to get rid of the GSDisplayServer queue is not a
good idea. I think r34553 is sensible, though, and it eliminates the bug I
mentioned in Ink.
Eric
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Slow application startup when using a theme
Hi Philippe, And there is a duplicate #import Foundation/NSNotification.h Thanks, fixed. - The code in [NSImage imageNamed:] could be simpified, not that the proxy is gone. We don't need to get the same image we just created from the dictionary. - I don't quite understand what happens when we switch back from having a theme to not using one. Will the standard GNUstep images get reused? The question here is whether we send the notification GSThemeDidActivateNotification when there is no theme at all. I tested it (by adding NSLog) and it works : when going back from Neos to native GNUstep theme, -themeDidActivate is called and the paths are recomputed and the bitmaps loaded if needed. Nitpicking : instead of registering for GSThemeDidActivateNotification for every image (and getting x notifications), it would probably be more efficient to register only once (but how ?) and check every image cached in nameDict. Good idea.. just implemented that by moving the notification registration to +[NSImage initialize]. Theme switching actually feels noticeably faster now which is odd; I wasn't expecting NSNotificationCenter to have much overhead. Anyway, this is a nice improvement of the code and of the user experience, I like it when my computer seems faster :o) Great :-) -Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Slow application startup when using a theme
How about adding caching to NSBundle? It already caches the budle info.plist, why not the directory listing of the resource directory? I hacked in some quick/dirty cacheing in NSBundle. Does it make enough difference to be worth doing properly rather than reverting? Yes, it makes a big improvement :-) before caching: startup Ink with Neos.theme: 183k syscalls after caching: startup Ink with Neos.theme: 11k syscalls Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Slow application startup when using a theme
Hi Fred, On 2012-01-09, at 2:26 PM, Fred Kiefer wrote: On 09.01.2012 20:59, Eric Wasylishen wrote: That would probably works but what about changing how +imageNamed: works ? When this method is called with a image name lacking an extension (ie 'GNUstep' or 'common_arrowLeft'), it tries to find a existing file by adding any know extension and calling a NSFileManager method, and this 3 times (main bundle, theme bundle and then every Images directory in the system). With bitmaps existing only in the system directories this is extremely costly as it tries something like 500 paths before the good one. (And I know you understand all that, I'm just filling the blanks for the others who might be interested, sorry :o) Couldn't we inverse the thing and check if one of the existing file in the directories has an extension known to be an image type ? I mean : list the files in the main bundle, look for the ones with a matching name (ie 'common_arrowLeft') and then check if the extension is none. The list of file in a bundle could also be cached. Worth trying ? That sounds like a good idea. Much of the overhead when using Neos is caused by the section of -[GSTheme activate] which loads all images in the theme. Here are some tests: startup Ink with default theme: 51k syscalls startup Ink with Neos.theme: 183k syscalls startup Ink with Neos.theme, with GSTheme.m lines 473 to 539 commented out: 95k syscalls. I am not completely sure why this code is that way. What I remember is that we need to override all the already loaded images. But there was more to it. It could have to do with unloading an image and restoring the previous image state. I hate the way we deal with images in themes and have often stated this, but haven't come up with a better idea up to now. I didn't like the current approach either… I just committed a rewrite of how theme images are handled which gets rid of theme proxies entirely, and eliminates the code in -[GSTheme activate] and -[GSTheme deactivate] which were setting/restoring images. Now, when a name is set on an NSImage instance, it also subscribes to the theme change notification. When an NSImage receives this notification, it does the name-to-path lookup again that +[NSImage imageNamed:] did, and reloads itself (discarding all reps) if the path has changed. It's a fairly major change but I tested Gorm, GSTest, SimpleAgenda, and tried switching between the GNUstep default theme, Neos, and Etoile's Nesedah theme while the apps were running, and all images seemed to update properly. Fred, even if we implement image filter services support and move the ImageMagick support to a service, +[NSImage imageNamed:] would still do just as much work because it uses [NSImage imageFileTypes], which would include the types supported by filter services. This is correct and it is what I already stated. My suggestion here was to rewrite imageNamed: to first check the unfiltered images and only later the filtered ones. Ah, I agree that sounds like a good idea. How about adding caching to NSBundle? It already caches the budle info.plist, why not the directory listing of the resource directory? Here the question is what should we cache? I'm not sure. The preliminary caching Richard just added makes a big difference as I reported (95% reduction in system calls, when using Neos.theme and the ImageMagick image rep is installed.) Also, it might be nice if NSBundle would have a private method: -(NSArray*)pathsForResource: (NSString*)name ofTypes: (NSArray*)types; Yes, this is exactly the method we should be using. That way we could also resolve the problem of inconsistent localisation, that is the case where we have localisation files with different extensions and for some cases fall back to the non localised versions, because they get found first. Ok, great. I'm not going to attempt this right now but it would be nice to do at some point. which given a name like @common_ArrowRight and a types array (@tiff, @png, … ) would return an array of paths to any matching resources in the bundle, and it would do so efficiently using a cache of the directory contents. Sounds great, I am just wondering how Apple gets by without this method? Not sure, perhaps they use a private method as well. Regards, Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Open/Save panel issue
Hi Sebastian, Thanks for the report… should be fixed now. -Eric On 2011-12-22, at 12:52 AM, Sebastian Reitenbach wrote: On Wednesday, December 21, 2011 07:46 CET, Eric Wasylishen ewasylis...@gmail.com wrote: Hi Germán, thanks for pointing that out. I inadvertently deleted the code to draw the highlighted background when working on NSBrowserCell - It should be fixed now. Do the file icons I added in the open/save dialog browsers look good? the icons are very close to each other, overlapping a bit, is that intended to be that way? Sebastian ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Open/Save panel issue
Hi Germán, thanks for pointing that out. I inadvertently deleted the code to draw the highlighted background when working on NSBrowserCell - It should be fixed now. Do the file icons I added in the open/save dialog browsers look good? -Eric On 2011-12-20, at 10:51 PM, Germán Arias wrote: Currently when you select a directory or a file in an Open/Save panel. Only appears a rectangle around the file or directory. As I remember, previously the file or directory was highlighted with a white background. Is this the new behavior or is a bug? ___ 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
64-bit NSNotFound breakage in gui
Hi, The recent change to increase NSNotFound on 64-bit breaks a lot of code in gui which stores NSNotFound in unsigned int. I think we should probably do a major search/replace on gui and update everything to NS[U]Integer and CGFloat, because it will continue to cause headaches if we don't. I don't have time to do this right away, though. Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r34174 - in /libs/gui/trunk: ChangeLog Headers/Additions/GNUstepGUI/GSTheme.h Source/GSTheme.m Source/GSThemeDrawing.m Source/NSMenuItemCell.m
Hi Fred and Quentin,
On 2011-11-22, at 8:17 AM, Quentin Mathé wrote:
Hi Quentin,
I like the changes you made for menu theming. And would like to use these as
a starting point for a bit of a general discussion on theming.
Sounds like a good idea.
Yes, agreed.
In this change you introduced a few new colour methods on GSTheme and
commented on another place in NSMenuItemCell.m
// TODO: Make the color lookup simpler.
Now the way we make the colour lookup in GSTheme was decided by Richard some
time ago. He wanted to have basic lookup methods for all the different theme
operations to be similar and came up with the current interface for colour
lookup. It is not that I like this interface that much, but we should try to
stay consistent. For this reason I think we should use this as the official
interface for GSTheme instead of introducing new methods as we go. I know I
did so myself for example for toolbar colours.
I must admit I don't know how to edit the color lists easily. Thematic only
knows about some precise colors but cannot edit arbitrary color lists.
For example, how can I make +[NSColor controlBackgroundColor] uses +[NSColor
greenColor] ? Can I do that with the built-in color picker ?
We also seem to have no tools to convert binary encoded NSColorList into the
ASCII format and vice-versa.
About the current API… The GSTheme color lookup API includes a method
-colorNamed:state:, but the state is almost never used based on a quick grep
over the Gui source code (only once in NSMenuItemCell.m). So I would remove
the last argument and encode the state within the color name. NSColor API
names the color like that, this approach would avoid to introduce two color
naming schemes (GTheme vs NSColor) for the themable colors.
The state arguments makes sense with the tile lookup methods, but for the
themable colors I'm not convinced.
Having color methods declared in GSTheme (such as the toolbar one) as
syntactic sugar over -colorNamed: doesn't go against the current color
lookup. It might even be a good way to clearly document the colors that can
be customized.
I like your new themeControlState method. We should use this in all the other
places where it is useful, for example in the method backgroundColor.
Yes, it could even be used in other classes such as -[NSButtonCell
drawBezelWithFrame:inView:].
This is actually the only place where you use one of your new colour methods
outside of the GSTheme class, maybe we should just change the lookup key here
to menuItemBackgroundColor and adjust all the themes?
For -[NSMenuItemCell backgroundColor], I would suggest to remove:
color = [[GSTheme theme] colorNamed: @NSMenuItem state: state];
if (color == nil)
and use either:
if ((state == GSThemeHighlightedState) || (state ==
GSThemeSelectedState))
{
color = [NSColor selectedMenuItemColor];
}
else
{
color = [[GSTheme theme] menuItemBackgroundColor];
}
or
if ((state == GSThemeHighlightedState) || (state ==
GSThemeSelectedState))
{
color = [NSColor selectedMenuItemColor];
}
else
{
color = [[GSTheme theme] colorNamed: @menuItemBackgroundColor];
}
Should I use this last solution?
Then there is this call in your code:
NSInterfaceStyleForKey(@NSMenuInterfaceStyle, nil);
We have plenty of similar calls all over the place, still I think this is
wrong. When ever possible we should pass in a responder as the second
argument of this function call. Every view is allowed to have its specific
interface style and at least the standard drawing code should respect this.
Themes may handle this differently or just ignore that value.
I'll remove this call in -menuSeparatorColor, it isn't needed now that the
Windows theme uses native menus as Gregory pointed it out in the bug report
#34792.
I agree about passing a responder every time to the GSTheme methods where it
makes sense, and limiting the number of places where we use
NSInterfaceStyleForKey(). Most uses of NSInterfaceStyleForKey() should be in
GSTheme subclasses I think.
And one final point. You us the method call [path setLineWidth: 0.0]; This
isn't as well defined as it may seem. Most people think that this will select
the smallest possible line width. At least with our current code this may not
be true for the cairo backend. There is a long and ongoing discussion about
zero line widths on the cairo mailing list.
ok, I wasn't aware of this issue. Which width should I use to get the
thinnest possible line or something close? 0.5 or 0.1 for example?
I added a fix to the cairo backend a few months ago which will interpret 0 as a
thin line (I think previously I broke a game which was relying on that
behaviour.)
However, I recommend drawing a filled rectangle instead of using lines. In
general, anywhere you
Re: preview: new macports ports
That sucks :-( Thanks for trying... The reason macports didn't uninstall the old versions of the ports may have been that I wasn't setting the version numbers on the ports properly. I fixed that, and also locked the SVN version that the ports check out for now, just so they're using a known-working version. On my OS 10.6.8 system I updated Xcode to 3.2.6, wiped Macports, and tried a fresh install of gorm, and was successful. Could you try running otool -L on a few binaries to see if anything is getting linked incorrectly? Here are the results I get: $ otool -L /opt/local/lib/libobjc-gnu.so.4.6.0 /opt/local/lib/libobjc-gnu.so.4.6.0: /opt/local/lib/libobjc-gnu.so.4.6.0 (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11) $ otool -L /opt/local/GNUstep/Local/Library/Libraries/libgnustep-base.1.23.dylib /opt/local/GNUstep/Local/Library/Libraries/libgnustep-base.1.23.dylib: /opt/local/GNUstep/Local/Library/Libraries/./libgnustep-base.1.23.dylib (compatibility version 0.0.0, current version 1.23.1) /opt/local/lib/libobjc-gnu.so.4.6.0 (compatibility version 0.0.0, current version 0.0.0) /opt/local/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.26.0) /opt/local/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.8.0) /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11) /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0) /opt/local/lib/libffi.5.dylib (compatibility version 6.0.0, current version 6.10.0) /opt/local/lib/libicui18n.48.dylib (compatibility version 48.0.0, current version 48.1.0) /opt/local/lib/libicuuc.48.dylib (compatibility version 48.0.0, current version 48.1.0) /opt/local/lib/libicudata.48.dylib (compatibility version 48.0.0, current version 48.1.0) $ otool -L `port dir gnustep-gui-devel`/work/trunk/Tools/obj/make_services /Users/ewasylishen/gnustep-macports-fixes/gnustep/gnustep-gui-devel/work/trunk/Tools/obj/make_services: /opt/local/lib/libicui18n.48.dylib (compatibility version 48.0.0, current version 48.1.0) /opt/local/lib/libicuuc.48.dylib (compatibility version 48.0.0, current version 48.1.0) /opt/local/lib/libicudata.48.dylib (compatibility version 48.0.0, current version 48.1.0) /opt/local/lib/libpng14.14.dylib (compatibility version 23.0.0, current version 23.0.0) /opt/local/GNUstep/Local/Library/Libraries/./libgnustep-base.1.23.dylib (compatibility version 0.0.0, current version 1.23.1) /opt/local/lib/libobjc-gnu.so.4.6.0 (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11) -Eric On 2011-11-19, at 2:50 AM, Ivan Vučica wrote: main.log ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: preview: new macports ports
Hmm.. it appears there is an old install of GNUstep in your /opt/local/GNUstep, and the build process is picking up headers from there causing the problem. (sarray.h is part of the apple runtime, I think, and the only place sarray.h is mentioned in base is at: macosx/GNUstepBase/preface.h:74: #include objc/sarray.h which I think is an old/unused file provided only for documentation purposes.) Try uninstalling gnustep-make, then just delete /opt/local/GNUstep. -Eric On 2011-11-18, at 1:20 PM, Ivan Vučica wrote: Hello, I'm having issues with gnustep-base-devel. This is on OS X 10.6 with Xcode 3.2.6. The-Evil-MacBook:macports ivucica$ clang --version clang version 2.9 (tags/RELEASE_29/final) Target: x86_64-apple-darwin10 Thread model: posix The-Evil-MacBook:macports ivucica$ which clang /opt/local/bin/clang Looks like clang warns about redefinition of __weak. Also, it appears clang cannot locate objc/sarray.h. :info:build In file included from GSObjCRuntime.m:32: :info:build In file included from .././common.h:30: :info:build In file included from /opt/local/GNUstep/Local/Library/Headers/Foundation/NSZone.h:57: :info:build In file included from /opt/local/GNUstep/Local/Library/Headers/Foundation/NSObjCRuntime.h:32: :info:build /opt/local/GNUstep/Local/Library/Headers/GNUstepBase/preface.h:78:11: fatal error: 'objc/sarray.h' file not found :info:build #include objc/sarray.h :info:build ^ I have also attached the log file. On Fri, Nov 18, 2011 at 20:18, Ivan Vučica ivuc...@gmail.com wrote: Zcode? Wow! *flattered* I really need to get back to working on it. I'm trying out the updated packages right now. On Thu, Nov 17, 2011 at 21:54, Eric Wasylishen ewasylis...@gmail.com wrote: Hi, Some updates on my macports (https://github.com/ericwa/gnustep-macports-fixes): I've switched them to use clang and libobjc2, and have done some tidying. They are now working on both of my systems: Mac OS 10.6.8 / Xcode 3.2.5 (x86_64) Mac OS 10.7.2 / Xcode 4.2 (x86_64) On 10.7, the system-provided clang is used; on 10.6 I install the clang port from macports (currently version 2.9. I couldn't get the system-provided clang, Apple version 1.6, to work.) Apps I've tested include GSTest, Gorm, and Zcode. Blocks and native ObjC exceptions seem to be working on both systems. -Eric On 2011-11-09, at 11:39 AM, Eric Wasylishen wrote: This is great! Thanks for your effort. Btw. are those ports going to be at the macports repository? I hope they will be accepted! There are several things I would like to do before submitting them to macports: - more testing - hopefully get them working on OS 10.7 (they probably would work if the gcc46 port wasn't broken :-) - the old ports contained some hacks for installing man pages/documentation... need to check if these are still needed - maybe investigate getting them to compile with clang - submit some of my patches to gnustep trunk - once the next release of GNUstep comes out, get ports working with that release (currently my ports require trunk) Cheers, Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev -- Ivan Vučica - i...@vucica.net -- Ivan Vučica - i...@vucica.net main.log ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: preview: new macports ports
Hi, Some updates on my macports (https://github.com/ericwa/gnustep-macports-fixes): I've switched them to use clang and libobjc2, and have done some tidying. They are now working on both of my systems: Mac OS 10.6.8 / Xcode 3.2.5 (x86_64) Mac OS 10.7.2 / Xcode 4.2 (x86_64) On 10.7, the system-provided clang is used; on 10.6 I install the clang port from macports (currently version 2.9. I couldn't get the system-provided clang, Apple version 1.6, to work.) Apps I've tested include GSTest, Gorm, and Zcode. Blocks and native ObjC exceptions seem to be working on both systems. -Eric On 2011-11-09, at 11:39 AM, Eric Wasylishen wrote: This is great! Thanks for your effort. Btw. are those ports going to be at the macports repository? I hope they will be accepted! There are several things I would like to do before submitting them to macports: - more testing - hopefully get them working on OS 10.7 (they probably would work if the gcc46 port wasn't broken :-) - the old ports contained some hacks for installing man pages/documentation... need to check if these are still needed - maybe investigate getting them to compile with clang - submit some of my patches to gnustep trunk - once the next release of GNUstep comes out, get ports working with that release (currently my ports require trunk) Cheers, Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-base create $HOME/GNUstep/Library
This sort of thing is a recurring (though infrequent) issue ... people who don't expect/want to see a GNUstep directory in their home directory, and who (often) actively dislike the presence of anything other than the folders they are force to have by their operating system. My impression is that the objection arises basically a certain sense of 'tidiness'. Why don't we just change to using .GNUstep instead of GNUstep by default? I think that's a great idea, for the default (FHS) filesystem layout. The FHS document (http://proton.pathname.com/fhs/pub/fhs-2.3.pdf) actually addresses this: 3.8.2. Requirements User specific configuration files for applications are stored in the user’s home directory in a file that starts with the ’.’ character (a dot file). If an application needs to create more than one dot file then they should be placed in a subdirectory with a name starting with a ’.’ character, (a dot directory). In this case the configuration files should not start with the ’.’ character. 11 --Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: preview: new macports ports
On 2011-11-08, at 1:59 PM, Ivan Vučica wrote: Hi Eric, I'm unable to build GNUstep due to no fault of your own: compiling gcc46 fails in the linking phase of libgcc_s.1.dylib. This is on Snow Leopard. Apparently gcc46 uses its own linker to link this library. For now, I am giving up. Can some older GCC be used if I am not interested in objc2.0 niceties? Hm, too bad. :-( When I install gcc46 on 10.6, macports uses this precompiled binary: http://packages.macports.org/gcc46/gcc46-4.6.2_0.darwin_10.x86_64.tbz2 , but maybe your system is not x86_64? I tried gcc44 and it doesn't work, unfortunately. Something wrong with detecting native exceptions. Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: preview: new macports ports
This is great! Thanks for your effort. Btw. are those ports going to be at the macports repository? I hope they will be accepted! There are several things I would like to do before submitting them to macports: - more testing - hopefully get them working on OS 10.7 (they probably would work if the gcc46 port wasn't broken :-) - the old ports contained some hacks for installing man pages/documentation... need to check if these are still needed - maybe investigate getting them to compile with clang - submit some of my patches to gnustep trunk - once the next release of GNUstep comes out, get ports working with that release (currently my ports require trunk) Cheers, Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
Hi Fred, I agree we should do a gui release as soon as possible - if I tested correctly, the latest gui release 0.20.0 doesn't work the the latest base, 1.23.0. I would like to get the changes you suggest in (font rewrite and filter services), but on the other hand, I think doing a release soon is more important - the font rewrite could be quite a lot of work - and we can simply remove the ImageMagick and Ghostscript image reps for now. As for the new cairo backend I added to back, we can either release with it or not. The resize flickering is definitely worse, but it supports some 16-bit configurations that were previously unsupported, and performs better over SSH. btw, I have an experimental branch of back at svn+ssh://eri...@svn.gna.org/svn/gnustep/libs/back/branches/ericwa-experimental , which only supports x11 and cairo with the new surface. The goal is to try to clean up XGServerWindow/Event, and get rid of all legacy or magic code. So far I deleted a lot of code from XGServerWindow, deleted XWindowBuffer, and got rid of styleoffset support. One of the changes I made (I think in XGServerWindow ) got rid of the resize flickering, the only problem is, I'm not sure exactly what the change was. Anyway, it's encouraging, at least. Cheers Eric On 2011-11-08, at 3:49 PM, Fred Kiefer wrote: For over a month I have been suggesting a new release of all GNUstep code components (perhaps including Gorm as well), but got no reply at all. Many of us have been pretty busy fixing the bugs Julian reported and there is still plenty to do in this area. Anyway I would like to start a discussion about this subject. After the last base release we did not make a gui/back release although some of the changes in base wont work with an old version of gui. This means anybody wanting to use GNUstep with a graphical user interface either has to use a very old release of all components or use SVN. The later is especially bad for distributions as they will have to ship an unclear state of the code. I will be away the first two weeks of December and would either like to see a release before that or after, but wont be available for last minute bug fixes during that period. There are a few changes to gui/back which I would like to see done before the release. One is the conversion of the Ghostscript and the ImageMagick bitmap implementations into filter services. The other is the integration of the real cairo font interface (instead of the currently used toy fonts) as prototyped in Opal. Is there anything important I did forget? It would be great if everybody could start to test its favourite application to find out whether any of the recent changes introduced new issues. What are the plans for GNUstep make and base? I think there have been enough changes in base that warrant a new release and gui requires some of these changes. For make there are a few open bug reports, maybe some of them could be fixed for the release? Please remember that this will be the first GNUstep release that requires gcc = 4.0. We decided so at the last base release and gui requires a current base version. ___ 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: preview: new macports ports
Ok, great! Here are a few more notes: - It installs using the GNUstep filesystem layout in /opt/local/GNUstep. Using the fhs layout with macports will not work, because gnustep-make adds the gnustep library path to DYLD_LIBRARY_PATH, which is /opt/local/lib with the fhs layout, and if you add /opt/local/lib to DYLD_LIBRARY_PATH it will mess up macports (basically, tools which link to apple versions of libraries will pick up the macports versions in /opt/local/lib and break.) - Many of the application ports work now (e.g., gorm, systempreferences). - gnustep-back is currently set to xlib. When I use cairo, opening an open/save panel crashes X11.app. Also tried the latest XQuartz: same problem. - For anyone with OS X 10.7, my ports won't work until this bug is fixed: https://trac.macports.org/ticket/31171 (building gcc46 on osx lion fails). :-( - One improvement that could be made in the future is to use the system compiler rather than the macports gcc46. For this we would need a portfile which builds one of GNUstep's libobjc's, and make sure that the apple compiler doesn't try to include headers for apple's libobjc. Regards Eric On 2011-11-07, at 10:52 AM, Ivan Vučica wrote: Hi Eric, I've cloned the repo, and will be trying it out soon on my Snow Leopard machine. If I forget to keep you posted, please poke me. On Mon, Oct 31, 2011 at 19:53, Eric Wasylishen ewasylis...@gmail.com wrote: Hi, I started a new set of macports ports. If you want to try it you can check out a copy of the git repository here: https://github.com/ericwa/gnustep-macports-fixes and then set up that directory as a local portfile repository (see http://guide.macports.org/#development.local-repositories). -- Ivan Vučica - i...@vucica.net ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
preview: new macports ports
Hi, I started a new set of macports ports. If you want to try it you can check out a copy of the git repository here: https://github.com/ericwa/gnustep-macports-fixes and then set up that directory as a local portfile repository (see http://guide.macports.org/#development.local-repositories). So far I've gotten gnustep-base-devel (which checks out the latest version of base from svn) to work quite well for me on OS X 10.6. The port uses macports-gcc-4.6 as a compiler. One nice thing - at least for 64-bit 10.6 - is macports has binary packages for most of the dependencies now, so you can try it out in a few minutes instead of a few hours. Here are the test results I got from base: 6361 Passed tests 16 Dashed hopes 7 Failed tests 1 Skipped set Failed test: NSGeometry1.m:102 ... In MacOSX geometry compat mode Failed test: create.m:26 ... +hostWithName: works for IPV6 addr Failed test: initialize.m:139 ... inherited +initialize is called automatically Failed test: performers.m:49 ... -performSelector:target:argument:order:modes: only sends the message once Failed test: performers.m:65 ... -performSelector:target:argument:order:modes: orders performers correctly Failed test: performers.m:89 ... -cancelPerformSelector:target:argument: works Failed test: thread.m:193 ... A loop with an input source will block Dashed hope: test02.m:284 ... foo-bar relative symlink not expanded by stringByResolvingSymlinksInPath Dashed hope: children.m:26 ... NSXML child handling working. Dashed hope: class_hierarchy.m:42 ... root class's metaclass is also its metaclass's metaclass Dashed hope: class_hierarchy.m:43 ... Root class is its metaclass's superclass Dashed hope: class_hierarchy.m:42 ... root class's metaclass is also its metaclass's metaclass Dashed hope: class_hierarchy.m:43 ... Root class is its metaclass's superclass Dashed hope: class_hierarchy.m:42 ... root class's metaclass is also its metaclass's metaclass Dashed hope: class_hierarchy.m:43 ... Root class is its metaclass's superclass Dashed hope: class_hierarchy.m:74 ... Metaclass's metaclass is root class's metaclass Dashed hope: class_hierarchy.m:74 ... Metaclass's metaclass is root class's metaclass Dashed hope: class_hierarchy.m:74 ... Metaclass's metaclass is root class's metaclass Dashed hope: class_hierarchy.m:74 ... Metaclass's metaclass is root class's metaclass Dashed hope: basic.m:53 ... working callStackSymbols ... if this has failed it is probably due to a lack of support for objective-c method names (local symbols) in the backtrace_symbols() function of your libc. If so, you might lobby your operating system provider for a fix. Dashed hope: general.m:125 ... Canonical identifier for 'AmericanEnglish is americanenglish Dashed hope: general.m:128 ... Canonical language identifier for 'AmericanEnglish is americanenglish Dashed hope: initialize.m:114 ... +initialize runs concurrently Skipped set: socket.m 146 ... NSStream SSL functions not supported --Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
migration to CGFloat for NSColor?
Hi, I started writing a patch to migrate NSColor to use CGFloat (in response to the bug report about -getComponents: taking a pointer to floats julian reported.) Of course, doing this will break any application code which uses that method. Do we want to do this? My feeling is, it is better to do it now than to postpone the change. I had to make updates in the color pickers, NSBitmapImageRep, and also updated the private -[NSGraphicsContext GSSetStroke/FillColor:] method to take CGFloat. There are also a lot of DPS/PS functions that take pointers to floats (for both setting colors, and font advances) - I guess those should not be modified, since that would break older OpenStep applications. Thoughts? Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: migration to CGFloat for NSColor?
On 2011-10-25, at 2:43 PM, Fred Kiefer wrote: On 25.10.2011 21:00, Eric Wasylishen wrote: Hi, I started writing a patch to migrate NSColor to use CGFloat (in response to the bug report about -getComponents: taking a pointer to floats julian reported.) Of course, doing this will break any application code which uses that method. Do we want to do this? My feeling is, it is better to do it now than to postpone the change. I had to make updates in the color pickers, NSBitmapImageRep, and also updated the private -[NSGraphicsContext GSSetStroke/FillColor:] method to take CGFloat. There are also a lot of DPS/PS functions that take pointers to floats (for both setting colors, and font advances) - I guess those should not be modified, since that would break older OpenStep applications. Thoughts? First off, it will only change things for 64bit systems, everything stays the same for 32bit. And even on 64 bit systems the compiler will convert most usages when recompiling existing applications. The problematic methods are the ones where we pass a pointer to a CGFloat value. These are the getXXX methods and colorWithColorSpace:components:count: and I would expect these get used less often in normal applications. So from my side this is a go forward advice. We need to rewrite the rest of gui to use CGFloat anyway, better we start off doing it now. I wouldn't touch the PS/DPS functions for now, the float precision is good enough anyway. Ok, I committed the patch. back needs to be recompiled because I changed the -GSSetStroke/FillColor: method on NSGraphicsContext. Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cairo x11 surfaces
Thanks for the feedback, everyone. Wolfgang, that's an interesting bug. I couldn't reproduce it with GNUstep running on Ubuntu 10.10 / x86-64 with cairo 1.10.0, exporting the display to a PowerPC iBook running OS X 10.4 and X11.app. What are the details of the setup you tested? My first thought is it might be a cairo bug since cairo handles all of the details of transferring surfaces to the X server with this new surface. Niels: that's interesting. I'll install kde and see if I can figure out why it is slow with compositing enabled. Phillipe, thanks for the update. I noticed some flickering too which I will investigate. -Eric On 2011-10-14, at 5:14 AM, Wolfgang Lux wrote: Eric Wasylishen wrote: I had a look at implementing it today, and it turned out to be easier than expected so I finished committed it. If we run in to problems we can switch back to XGCairoXImageSurface before the next release, but it looks promising. In particular, I tried X forwarding to Apple's X11.app, which only supports 24-bit windows, and the new surface is significantly faster than XGCairoXImageSurface, and the alpha channel of images is correctly preserved (unlike XGCairoSurface). Riccardo, this should fix GNUstep on the 16-bit display configuration where it wasn't working for you. If you could test it some time and let me know if it works, that would be great. Nice change. However it has a subtle endianness bug. When the display is on a machine with a different endianness than the machine running the application (e.g., PowerPC vs. x86), the colours of all icons are displayed incorrectly. See the SystemPreferences and Color panel screenshots below. Wolfgang SystemPreferences.tiffColorPanel.tiff ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cairo x11 surfaces
Hi Fred, I had a look at implementing it today, and it turned out to be easier than expected so I finished committed it. If we run in to problems we can switch back to XGCairoXImageSurface before the next release, but it looks promising. In particular, I tried X forwarding to Apple's X11.app, which only supports 24-bit windows, and the new surface is significantly faster than XGCairoXImageSurface, and the alpha channel of images is correctly preserved (unlike XGCairoSurface). Riccardo, this should fix GNUstep on the 16-bit display configuration where it wasn't working for you. If you could test it some time and let me know if it works, that would be great. Cheers, Eric On 2011-10-13, at 1:08 AM, Fred Kiefer wrote: This sounds very promising. Maybe we can get rid of XWindowBuffer that way. Do you think this change should go in before the release or after? Fred On 12.10.2011 18:54, Eric Wasylishen wrote: Hi, I just wanted to report on a bit of research I did on this. There was a suggestion on the cairo mailing list [1] to implement double buffering on X by doing the following: - create a cairo xlib surface for the window (could be 32-bpp with alpha, 16-bpp no alpha, etc.) - call cairo_surface_create_similar [2] with CAIRO_CONTENT_COLOR_ALPHA. As far as I know the resulting surface is guaranteed to have an alpha channel. I skimmed over the implementation and it looks like it tries to create an xlib surface with alpha; if that fails, it creates a 32-bpp image surface and returns that. - when expose events are received, use cairo drawing methods to copy the desired region from the back buffer to the window. This should boil down to a efficient X call if both surfaces are stored on the server, or otherwise cairo should handle using shared memory to transfer the 32bpp image surface to the X server, and converting it to the needed format. Now, I haven't tested this, but it looks like it should work and looks like exactly the behaviour we want, and as a bonus, cairo does all of the messy/hard work. :-) It's amazingly hard to find tutorials on how to set up double buffering. Here's another comment I found: A conversation with keithp indicates that his current thinking is that the right way to do double buffering is via an explicit copy from a separate pixmap. This is portable to absolutely everywhere, and requires no magic. Probably there will soon be a convention for the compositing manager to handle the double buffering on systems where one is running, since it needs to buffer anyhow. But this would be in the future. [3] --Eric [1] http://lists.freedesktop.org/archives/cairo/2007-February/009586.html [2] http://www.cairographics.org/manual/cairo-cairo-surface-t.html#cairo-surface-create-similar [3] http://xcb.freedesktop.org/XcbNotes/ ___ 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: cairo x11 surfaces
Forgot to add, thanks to Matt Rice for sending me some example code of this technique. On 2011-10-13, at 3:26 PM, Eric Wasylishen wrote: Hi Fred, I had a look at implementing it today, and it turned out to be easier than expected so I finished committed it. If we run in to problems we can switch back to XGCairoXImageSurface before the next release, but it looks promising. In particular, I tried X forwarding to Apple's X11.app, which only supports 24-bit windows, and the new surface is significantly faster than XGCairoXImageSurface, and the alpha channel of images is correctly preserved (unlike XGCairoSurface). Riccardo, this should fix GNUstep on the 16-bit display configuration where it wasn't working for you. If you could test it some time and let me know if it works, that would be great. Cheers, Eric On 2011-10-13, at 1:08 AM, Fred Kiefer wrote: This sounds very promising. Maybe we can get rid of XWindowBuffer that way. Do you think this change should go in before the release or after? Fred On 12.10.2011 18:54, Eric Wasylishen wrote: Hi, I just wanted to report on a bit of research I did on this. There was a suggestion on the cairo mailing list [1] to implement double buffering on X by doing the following: - create a cairo xlib surface for the window (could be 32-bpp with alpha, 16-bpp no alpha, etc.) - call cairo_surface_create_similar [2] with CAIRO_CONTENT_COLOR_ALPHA. As far as I know the resulting surface is guaranteed to have an alpha channel. I skimmed over the implementation and it looks like it tries to create an xlib surface with alpha; if that fails, it creates a 32-bpp image surface and returns that. - when expose events are received, use cairo drawing methods to copy the desired region from the back buffer to the window. This should boil down to a efficient X call if both surfaces are stored on the server, or otherwise cairo should handle using shared memory to transfer the 32bpp image surface to the X server, and converting it to the needed format. Now, I haven't tested this, but it looks like it should work and looks like exactly the behaviour we want, and as a bonus, cairo does all of the messy/hard work. :-) It's amazingly hard to find tutorials on how to set up double buffering. Here's another comment I found: A conversation with keithp indicates that his current thinking is that the right way to do double buffering is via an explicit copy from a separate pixmap. This is portable to absolutely everywhere, and requires no magic. Probably there will soon be a convention for the compositing manager to handle the double buffering on systems where one is running, since it needs to buffer anyhow. But this would be in the future. [3] --Eric [1] http://lists.freedesktop.org/archives/cairo/2007-February/009586.html [2] http://www.cairographics.org/manual/cairo-cairo-surface-t.html#cairo-surface-create-similar [3] http://xcb.freedesktop.org/XcbNotes/ ___ 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
cairo x11 surfaces
Hi, I just wanted to report on a bit of research I did on this. There was a suggestion on the cairo mailing list [1] to implement double buffering on X by doing the following: - create a cairo xlib surface for the window (could be 32-bpp with alpha, 16-bpp no alpha, etc.) - call cairo_surface_create_similar [2] with CAIRO_CONTENT_COLOR_ALPHA. As far as I know the resulting surface is guaranteed to have an alpha channel. I skimmed over the implementation and it looks like it tries to create an xlib surface with alpha; if that fails, it creates a 32-bpp image surface and returns that. - when expose events are received, use cairo drawing methods to copy the desired region from the back buffer to the window. This should boil down to a efficient X call if both surfaces are stored on the server, or otherwise cairo should handle using shared memory to transfer the 32bpp image surface to the X server, and converting it to the needed format. Now, I haven't tested this, but it looks like it should work and looks like exactly the behaviour we want, and as a bonus, cairo does all of the messy/hard work. :-) It's amazingly hard to find tutorials on how to set up double buffering. Here's another comment I found: A conversation with keithp indicates that his current thinking is that the right way to do double buffering is via an explicit copy from a separate pixmap. This is portable to absolutely everywhere, and requires no magic. Probably there will soon be a convention for the compositing manager to handle the double buffering on systems where one is running, since it needs to buffer anyhow. But this would be in the future. [3] --Eric [1] http://lists.freedesktop.org/archives/cairo/2007-February/009586.html [2] http://www.cairographics.org/manual/cairo-cairo-surface-t.html#cairo-surface-create-similar [3] http://xcb.freedesktop.org/XcbNotes/ On 2011-09-19, at 4:37 AM, Fred Kiefer wrote: On 19.09.2011 08:49, Riccardo Mottola wrote: Sorry, I was premature to commit that; I was hoping to work on it yesterday but didn't have time, so 'll revert it for now. I did some testing with Riccardo and we found that using XGCairoSurface (so using cairo xlib surfaces) did indeed fix the problem he was observing. By switching to XGCairoSurface we get: - much better drawing performance for X over ssh (tested) - potentially better drawing performance overall (not tested, but reported on the cairo mailing list) - better font rendering (subpixel antialiasing support) - support for running on X servers only supporting 16-bit visuals, whereas XGCairoXImageSurface fails completely - delegate more work to cairo and rely less on XWindowBuffer (e.g. cairo handles shared memory) Indeed. Essentially one of the objections that was made to XGCairoSurface was transparent windows on non-32bit displays. My main development workstation is 32bit capable but is set as default to 24bit. The same is true for my laptop. I am able to get the opacity test in GSTest for both surface types on 24bit. (I can't get the same compositing effect to work with the alpha channel of NSColor in neither cases). So essentially, I found no problems on 24bit and on 16bit the situation improved a lot. Most probably without image caching it would have worked. Eric still hoped to find a buffer which would abstract the depth level, but apparently art doesn't use that either. Did you have any problems with XGCairoSurface, Fred? No, and I never said so. I just wanted to know the reason why Eric made a commit he had argued against. I am working with 32 bit visuals and things are OK either way on my machine. ___ 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
Shal we do a gui code freeze?
Hi, I notice there's been a pause in activity on gui for a few weeks- how would everyone feel about starting a code freeze now, testing for a few weeks, and then doing a release? I would also be fine with waiting to integrate the menu work Fred started. Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: base patch for review: NSLanguages system languages
Hey, I committed this. IIRC I checked the glib source code and it does something similar, so the most generalized version of fr_CA (which is fr) is still preferred over the locales appearing later in the list (in my example, just en). Eric On 2011-09-08, at 12:02 PM, Ivan Vučica wrote: On Thu, Sep 8, 2011 at 09:48, Fred Kiefer fredkie...@gmx.de wrote: You are aware that your last example, de:fr_CA:en, will result in something like (German, CanadianFrench, French, English)? I think is is debatable where French should be put in this list, but the current solution is fine with we. CanadianFrench is more specific than French. If the strings are pulled first from CanadianFrench, and, upon failure, from French (as it should), then this order is more than correct - it's perfect. French language, as a base language, being patched with CanadianFrench sounds correct. -- Ivan Vučica - i...@vucica.net ___ 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 compile
Yeah, I should have mentioned that you should always use sudo -E (preserve environment variables) when using GNUstep make. So starting from scratch again, it would be: (I'd suggest trying the default install path with no prefix for now - it will install in subdirectories of /usr/local/): cd core cd make ./configure make sudo -E make install . /usr/local/share/GNUstep/Makefiles/GNUstep.sh # note that the command starts with period, space, forward-slash! cd .. cd base ./configure make sudo -E make install cd .. cd gui ./configure make sudo -E make install cd .. cd back ./configure make sudo -E make install cd .. Hope this helps Eric On 2011-09-26, at 7:39 AM, Jackie Gleason wrote: Hey that was great, I think you might have given me an idea. I tried running all of them using sudo -s instead of the sudo command (you gave me the idea that it was creating a new token everytime) this seems to have worked. That list might be good to add to the wiki, of course I don't have access but someone may want to. Thanks to everyone for their help I will keep testing it out. Jackie ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
gnustep-howto documentation update
Hi, I committed some changes to the gnustep-howto.texi document, updating the section on library dependencies, and also suggesting the use of sudo -E when running make install. I also noticed that the copy on the web site needs to be regenerated some time: http://www.gnustep.org/resources/documentation/User/GNUstep/gnustep-howto_3.html Cheers Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem with compile
Hey,
To use NSLog, NSString, and even constant strings (@), you need to import the
GNUstep base headers.
Adding:
#import Foundation/Foundation.h
to the top of your source.m file should fix the problem. :-)
Eric
On 2011-09-24, at 10:56 AM, Jackie Gleason wrote:
I am trying to compile the following code
Environment: Ubuntu 11.04 x64
int main(void)
{
NSString* s = @Hello, world!;
NSLog(s);
//printf(%s\n, [Test classStringValue]);
return 0;
}
I install and Compile GNUstep by checking out the anonymous core, then
compiling in the order make, base, gui, back. I compile all of them using the
following command (under sudo shell)..
./configure --prefix=/usr/GnuStep
make
make install
After make I run the following...
. /usr/GnuStep/share/GNUstep/Makefiles/GNUstep.sh
Finally I create the following GNUMakeFile...
include $(GNUSTEP_MAKEFILES)/common.make
TOOL_NAME = LogTest
LogTest_OBJC_FILES = source.m
include $(GNUSTEP_MAKEFILES)/tool.make
But when I try running I get the following message...
~/Development/Code/personal/GnuStep/helloWorld$ make
This is gnustep-make 2.6.1. Type 'make print-gnustep-make-help' for help.
Making all for tool LogTest...
Compiling file source.m ...
source.m: In function ‘main’:
source.m:36:3: error: cannot find interface declaration for ‘NXConstantString’
make[3]: *** [obj/LogTest.obj/source.m.o] Error 1
make[2]: *** [internal-tool-all_] Error 2
make[1]: *** [LogTest.all.tool.variables] Error 2
make: *** [internal-all] Error 2
the ls for the folder is...
:/usr/GnuStep# ls
bin share
Any help would be very appreciated.
___
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 compile
Hm, I'm not sure what is going on. Your install procedure looks correct and
I've used a very similar procedure on Ubuntu 11.04 successfully.
Here's another test program you could try which avoids constant strings:
#import Foundation/Foundation.h
#include stdio.h
int main(int argc, const char **argv)
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
printf(testing NSNumber: %d\n, [[NSNumber numberWithInt: 3]
intValue]);
[pool release];
return 0;
}
Also, could you try running make with make messages=yes? This will log the
full command line used to run gcc.
How did you install the objective-C compiler and runtime? Just through the
gobjc package?
-Eric
On 2011-09-25, at 11:03 AM, Jackie Gleason wrote:
Sorry, I was trying not to send the whole code, probably should have included
that.
Anyway still looking for an answer, I believe it has something to do with the
way I am compiling from source since I don't see a Libraries folder under
/usr/GnuStep
#include stdio.h
#import Foundation/Foundation.h
/*
* The next #include line is generally present in all Objective-C
* source files that use GNUstep. The Foundation.h header file
* includes all the other standard header files you need.
*/
/*
* Declare the Test class that implements the class method (classStringValue).
*/
@interface Test
+ (const char *) classStringValue;
@end
/*
* Define the Test class and the class method (classStringValue).
*/
@implementation Test
+ (const char *) classStringValue;
{
return This is the string value of the Test class;
}
@end
/*
* The main() function: pass a message to the Test class
* and print the returned string.
*/
int main(void)
{
NSString* s = @Hello, world!;
NSLog(s);
//printf(%s\n, [Test classStringValue]);
return 0;
}
Same issue is still happening
On Sun, Sep 25, 2011 at 12:51 PM, Eric Wasylishen ewasylis...@gmail.com
wrote:
Hey,
To use NSLog, NSString, and even constant strings (@), you need to import
the GNUstep base headers.
Adding:
#import Foundation/Foundation.h
to the top of your source.m file should fix the problem. :-)
Eric
On 2011-09-24, at 10:56 AM, Jackie Gleason wrote:
I am trying to compile the following code
Environment: Ubuntu 11.04 x64
int main(void)
{
NSString* s = @Hello, world!;
NSLog(s);
//printf(%s\n, [Test classStringValue]);
return 0;
}
I install and Compile GNUstep by checking out the anonymous core, then
compiling in the order make, base, gui, back. I compile all of them using
the following command (under sudo shell)..
./configure --prefix=/usr/GnuStep
make
make install
After make I run the following...
. /usr/GnuStep/share/GNUstep/Makefiles/GNUstep.sh
Finally I create the following GNUMakeFile...
include $(GNUSTEP_MAKEFILES)/common.make
TOOL_NAME = LogTest
LogTest_OBJC_FILES = source.m
include $(GNUSTEP_MAKEFILES)/tool.make
But when I try running I get the following message...
~/Development/Code/personal/GnuStep/helloWorld$ make
This is gnustep-make 2.6.1. Type 'make print-gnustep-make-help' for help.
Making all for tool LogTest...
Compiling file source.m ...
source.m: In function ‘main’:
source.m:36:3: error: cannot find interface declaration for
‘NXConstantString’
make[3]: *** [obj/LogTest.obj/source.m.o] Error 1
make[2]: *** [internal-tool-all_] Error 2
make[1]: *** [LogTest.all.tool.variables] Error 2
make: *** [internal-all] Error 2
the ls for the folder is...
:/usr/GnuStep# ls
bin share
Any help would be very appreciated.
___
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: [Gnustep-cvs] r33849 - in /libs/back/trunk: ChangeLog Source/cairo/CairoContext.m
Hi Fred, On 2011-09-18, at 5:20 AM, Fred Kiefer wrote: On 17.09.2011 01:56, Eric Wasylishen wrote: Author: ericwa Date: Sat Sep 17 01:56:01 2011 New Revision: 33849 URL: http://svn.gna.org/viewcvs/gnustep?rev=33849view=rev Log: * Source/cairo/CairoContext.m: Switch to XGCairoSurface by default, because it fixes the corrupted display problem reported by Riccardo on 16-bit displays. Modified: libs/back/trunk/ChangeLog libs/back/trunk/Source/cairo/CairoContext.m I am surprised you made this change. After your last mails on the mailing list I thought you had given up this idea, as the problems are about as big as the benefits. Could you please explain what changed your mind? Fred Sorry, I was premature to commit that; I was hoping to work on it yesterday but didn't have time, so 'll revert it for now. I did some testing with Riccardo and we found that using XGCairoSurface (so using cairo xlib surfaces) did indeed fix the problem he was observing. By switching to XGCairoSurface we get: - much better drawing performance for X over ssh (tested) - potentially better drawing performance overall (not tested, but reported on the cairo mailing list) - better font rendering (subpixel antialiasing support) - support for running on X servers only supporting 16-bit visuals, whereas XGCairoXImageSurface fails completely - delegate more work to cairo and rely less on XWindowBuffer (e.g. cairo handles shared memory) The only problem with XGCairoSurface is it might not be able to create a surface with alpha - it might be 32-bit argb, 32-bit no-alpha, or 16-bit no-alpha. However, e.g. locking focus on an image is one place in gui where we need a surface with alpha, even if the window server doesn't support alpha. What I wanted to do is extend XGCairoSurface so it can always create 32-bit ARGB surfaces, by delegating as much of the work to cairo as possible: - create a cairo xlib surface at whatever depth the X server supports. If it supports alpha, we can use it directly, otherwise we can: - create a 32-bit ARGB cairo image surface - use the ARGB image surface as the destination for drawing, and use cairo to copy regions of the image surface to the xlib surface when it is time to display the window. This will probably be slow, so we won't want to try to do image caching as a performance optimization unless the server actually supports native 32-bit surfaces. However, it should be fairly simple to implement, produce correct output, and should work on any X server. Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Other graphic issues
I wasn't able to reproduce this either, but I committed a patch which gets rid of the artifacts in ImageSelection-test. Eric On 2011-09-06, at 6:39 PM, Germán Arias wrote: I will check the gorm files. Anyway I'm thinking reimplement the panel. If I will add more elements in each release, will be so difficult maintain the gorm file. Thanks. On mar, 2011-09-06 at 22:47 +0200, Fred Kiefer wrote: I think Eric is correct here. I checked the Grom file and the buttons are positioned on half pixels. We need to change the code to get more reliable results here, but for now it seems easier to adjust FisicaLab. Fred On 06.09.2011 20:44, Eric Wasylishen wrote: I haven't had a look at Fisicalab yet, but something which may or may not be related is the artifacting I get in GSTest/ImageSelection-test. It happens when moving the sliders to adjust the image size; the image can leave lines as it's being resized, but the same code works fine on OS X. The artifacting seems to to come from calling [aView setNeedsDisplayInRect:] with a non-integral rect. I suspect at some point the rect coordinates are being floor()'ed, which would be incorrect. If we mark a (possibly non-integral) region of a view as needing to be redrawn, at some point we'll need to compute a pixel aligned version that completely encloses the original rect. -Eric On 2011-09-05, at 3:47 AM, Fred Kiefer wrote: On 05.09.2011 02:26, Germán Arias wrote: Currently when I select an element in FisicaLab an ugly lines appears. See attached image. I'm using cairo backend. I tried to reproduce this behaviour with Fisicalab 0.2.1 and current SVN GNUstep code and failed to get these artefacts. I am using the cairo backend as well. Could you please give some more details on how to reproduce this? ___ 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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
base patch for review: NSLanguages system languages
Hi, I was experimenting with changing my system language (Ubuntu 10.10) and ran in to a problem: I set the language in Ubuntu's language settings tool to Canadian French but was not getting any French translations showing up in GNUstep apps. I didn't touch the NSLanguages user default, but when I tried reading it in an application, it returned (CanadianFrench, English). The following patch fixes this problem by expanding regional locales into their more general variants - so CanadianFrench is expanded to (CanadianFrench, French) Also, it adds support for reading the LANGUAGE environment variable, a GNU extension, which lets you specify a list of locales like de:fr_CA:en if you wanted to see German, then Canadian French, then English in order of preference. In other words, it has the same role as the GNUstep LANGUAGES environment variable, but it's used by GNU gettext/gtk/probably others. According to the gettext docs, if LANGUAGE is set it is supposed to take precedence over LC_MESSAGES and LANG. Languages5.diff Description: Binary data Cheers, Eric___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Other graphic issues
I haven't had a look at Fisicalab yet, but something which may or may not be related is the artifacting I get in GSTest/ImageSelection-test. It happens when moving the sliders to adjust the image size; the image can leave lines as it's being resized, but the same code works fine on OS X. The artifacting seems to to come from calling [aView setNeedsDisplayInRect:] with a non-integral rect. I suspect at some point the rect coordinates are being floor()'ed, which would be incorrect. If we mark a (possibly non-integral) region of a view as needing to be redrawn, at some point we'll need to compute a pixel aligned version that completely encloses the original rect. -Eric On 2011-09-05, at 3:47 AM, Fred Kiefer wrote: On 05.09.2011 02:26, Germán Arias wrote: Currently when I select an element in FisicaLab an ugly lines appears. See attached image. I'm using cairo backend. I tried to reproduce this behaviour with Fisicalab 0.2.1 and current SVN GNUstep code and failed to get these artefacts. I am using the cairo backend as well. Could you please give some more details on how to reproduce this? ___ 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
Theme API break for button borders
Hi,
I made a small change to the theme API yesterday:
- (NSSize) buttonBorderForCell: (NSCell*)cell
style: (int)style
state: (GSThemeControlState)state;
is changed to:
typedef struct GSThemeMargins
{
CGFloat left;
CGFloat right;
CGFloat top;
CGFloat bottom;
} GSThemeMargins;
- (GSThemeMargins) buttonMarginsForCell: (NSCell*)cell
style: (int)style
state: (GSThemeControlState)state;
Now we can properly handle buttons where the content area's margins are
different on all four sides.
I also made a slight adjustment to the metrics for the default NeXT-style
button: instead of a 3pt border on all sides, it now has a 2 pt border on the
top and left and 3pt on the right and bottom. This better matches how the
button looks, and fixes the problem of scroller arrows looking off-center.
Hopefully this doesn't cause too problems for anyone, but if it does, we can
revert it.
Eric
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
gui release?
Hi, I just wanted to verify that gui isn't in code freeze, because I've been committing some new things lately. Does anyone have thoughts on when we should do a gui release?Maybe in September or October? Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
