Re: Theme problem with first responder

[Eric Wasylishen]

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"  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.
> 
>
> 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

[Eric Wasylishen]

Hi Riccardo, +Fred +gnustep-dev

On Dec 18, 2013, at 7:40 AM, Riccardo Mottola  
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

[Eric Wasylishen]

Thanks for the report! This one should be fixed now as well.

It was a small code change but the explanation behind it is long; see ChangeLog 
for more detail. The cause was an earlier change I made for NSTabView to use 
flipped coordinates, and now the NSTabView subview frames in archives are 
incorrect.

Eric

On 2013-10-14, at 10:59 PM, Germán Arias  wrote:

> El lun, 14-10-2013 a las 22:23 -0600, Eric Wasylishen escribió:
>> Hi Germán,
>> I think I see the problem, can you update gui and see if it's fixed for you?
>> 
>> Looks like another case of stack corruption cause by:
>> 
>> NSImage *img = ;
>> NSSize s = [img size];
>> 
>> Eric
>> 
> 
> Thanks, now works. But there is still other problem. See attached image,
> that show the Gorm's inspector.
> 
> Germán.
> 
> 
> 


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Problem with tabviews

[Eric Wasylishen]

Hi Germán,
I think I see the problem, can you update gui and see if it's fixed for you?

Looks like another case of stack corruption cause by:

NSImage *img = ;
NSSize s = [img size];

Eric

On 2013-10-14, at 9:38 PM, Germán Arias  wrote:

> With current SVN I can't launch FisicaLab or open the main gorm file.
> This is the backtrace:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00846ffe in _OBJC_SELECTOR_TABLE ()
>   from /usr/GNUstep/Local/Library/Libraries/libgnustep-gui.so.0.23
> (gdb) backtrace
> #0  0x00846ffe in _OBJC_SELECTOR_TABLE ()
>   from /usr/GNUstep/Local/Library/Libraries/libgnustep-gui.so.0.23
> #1  0x006af8e4 in -[GSTheme(Drawing)
> drawTabViewRect:inView:withItems:selectedItem:] (self=0x831c330,
> _cmd=0x7f2ca0, rect=..., view=0x83fbd20,
>items=0x8649090, selected=0x86490c0) at GSThemeDrawing.m:2073
> #2  0x005d933d in -[NSTabView drawRect:] (self=0x83fbd20, _cmd=0x8179c0,
>rect=...) at NSTabView.m:469
> #3  0x006403ae in -[NSView displayRectIgnoringOpacity:inContext:] (
>self=0x83fbd20, _cmd=0x8179b0, aRect=..., context=)
>at NSView.m:2570
> #4  0x006405ce in -[NSView displayRectIgnoringOpacity:inContext:] (
>self=0x83fb630, _cmd=0x8179b0, aRect=..., context=)
>at NSView.m:2604
> #5  0x006405ce in -[NSView displayRectIgnoringOpacity:inContext:] (
>self=0x83f9468, _cmd=0x8179b0, aRect=..., context=)
>at NSView.m:2604
> #6  0x00631261 in -[NSView displayRectIgnoringOpacity:] (self=0x83f9468,
>_cmd=0x8179a0, aRect=...) at NSView.m:2519
> #7  0x0063e301 in -[NSView displayIfNeededInRectIgnoringOpacity:] (
>self=0x83f9468, _cmd=0x817990, aRect=...) at NSView.m:2450
> #8  0x006310a3 in -[NSView displayIfNeededInRect:] (self=0x83f9468,
>_cmd=0x817988, aRect=...) at NSView.m:2428
> #9  0x00630e82 in -[NSView displayIfNeeded] (self=0x83f9468,
> _cmd=0x81e720)
>at NSView.m:2410
> ---Type  to continue, or q  to quit---
> #10 0x0064a7a6 in -[NSWindow orderWindow:relativeTo:] (self=0x83f8a48,
>_cmd=0x81e6d8, place=NSWindowAbove, otherWin=0) at NSWindow.m:1826
> #11 0x006459e9 in -[NSWindow orderFront:] (self=0x83f8a48,
> _cmd=0x83c6d8,
>sender=0x833a200) at NSWindow.m:1723
> #12 0x006969d1 in -[GSNibContainer awakeWithContext:] (self=0x833a200,
>_cmd=0x854508, context=0x87fade8) at GSGormLoading.m:294
> #13 0x006cf047 in -[GSGormLoader
> loadModelData:externalNameTable:withZone:] (
>self=0x81f49a0, _cmd=0x7c5110, data=0x81f2bc0, context=0x8360810,
>zone=0xcdeb80) at GSGormLoader.m:120
> #14 0x00574d77 in -[NSNib instantiateNibWithExternalNameTable:withZone:]
> (
>self=0x82c6bc8, _cmd=0x7792f0, externalNameTable=0x8360810,
> zone=0xcdeb80)
>at NSNib.m:153
> #15 0x004c5525 in +[NSBundle(NSBundleAdditions)
> loadNibFile:externalNameTable:withZone:] (self=0xc77a00, _cmd=0x779378,
> fileName=0x8227748, context=0x8360810,
>zone=0xcdeb80) at NSBundleAdditions.m:235
> #16 0x004c5439 in -[NSBundle(NSBundleAdditions)
> loadNibFile:externalNameTable:withZone:] (self=0x8212a08, _cmd=0x779318,
> fileName=0x81f7650,
>context=0x8360810, zone=0xcdeb80) at NSBundleAdditions.m:342
> #17 0x004c5704 in +[NSBundle(NSBundleAdditions) loadNibNamed:owner:] (
>self=0xc77a00, _cmd=0x7602f8, aNibName=0x81f7650, owner=0x8238678)
>at NSBundleAdditions.m:277
> #18 0x004739cc in NSApplicationMain (argc=1, argv=0xbfffe374) at
> Functions.m:83
> #19 0x08049f37 in main (argc=1, argv=0xbfffe374) at main.m:30
> 
> 
> 
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

themes: highlighted cell text colors

[Eric Wasylishen]

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

[Eric Wasylishen]

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  wrote:

> On 4. 10. 2013., at 21:50, Eric Wasylishen  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

[Eric Wasylishen]

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

[Eric Wasylishen]

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  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

[Eric Wasylishen]

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  wrote:

> For the moment, the one problem that I can reproduce is this:
> 
> On 2013-08-28 01:12:38 -0600 Fred Kiefer  wrote:
>>> 
>>> On 2013-08-27 22:35:49 -0600 Germán Arias  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?]

[Eric Wasylishen]

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

[Eric Wasylishen]

Hey Stef,

I think what GNUstep is doing is OK...

On 2013-08-20, at 3:34 PM, Stefan Bidi  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

[Eric Wasylishen]

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  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
> ___
> 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

[Eric Wasylishen]

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  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...

[Eric Wasylishen]

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  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 
>  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 mysel

Re: GNUstep don't load images of current theme.

[Eric Wasylishen]

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  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 
>  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.

[Eric Wasylishen]

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" 
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-dev
>
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

NSUUID patch

[Eric Wasylishen]

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: MAC_OS_X_VERSION macros

[Eric Wasylishen]

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  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  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  写道：
> 
>> 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 defi

Re: GNUStep Themeing - Menu Groove

[Eric Wasylishen]

Hi Aaron,You can get rid of those borders by setting GSMenuVerticalBackground; 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 in Menu.9.png red to verify that it works :-)EricOn 2013-06-23, at 1:29 AM, Germán Arias  wrote:On 2013-06-22 06:41:42 -0600 aaroncarr  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?

[Eric Wasylishen]

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"  wrote:

> Hi,
>
> I'm still working on getting the latest The Unarchiver for OS X <
> http://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:
>
> 
>   -2076180416
>   2048
>   
>   
>   109199360<**/int>
>   1
>   
>   
>   
> 
>   
>   400
>   75
>
>   
>
>dummy
>
>**1048576
>2147483647
>1
>
>
>_**popUpItemAction:
>
>   
>
> (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 ) at GSNibLoader.m:87
> #5  0x7753f57d in -[NSNib 
> instantiateNibWithExternalName**Table:withZone:]
> (self=0xecf938, _cmd=0x779f7b00 <.objc_selector_list+160>,
> externalNameTable=0xcb09f8,
> zone=0x329060bb38 ) 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 ) 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 ) 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 NSCell.m:234
> #4  0x77455537 in -[NSButtonCell dealloc] (self=0x1843d58,
> _cmd=0x77a53ec0 <.objc_selector_list+832>) at NSButtonCell.m:185
> #5  0x775390b0 in -[NSMenuItemCell dealloc] (self=0x1843d58,
> _cmd=0x77a6c490 <.objc_selector_list+1856>) at NSMenuItemCell.m:112
> #6  0x7755cd05 in -[NSPopUpButtonCell dealloc] (self=0x1843d58,
> _cmd=0x76678370 <.objc_selector_list+560>) at NSPopUpButtonCell.m:158
> #7  0x76173739 in -[NSObject release] (self=0x1843d58,
> _cmd=0x76662ff0 <.objc_selector_list+784>) at NSObject.m:2070
> #8  0x761391b4 in GSIArraySetItemAtIndex (array=0x13b6770,
> item=..., index=66) at ../Headers/GNUstepBase/**GSIArray.h:531
> #9  0

Re: Position of I-beam cursor

[Eric Wasylishen]

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: [GSoC Mentors Announce] Google Summer of Code 2013

[Eric Wasylishen]

Hi Fred, Ivan,

I'd be interested in mentoring a backend/Opal related project, or at least 
offering guidance if we have a mentor already.
I guess I have to register on the GSoC site?

Eric

On 2013-04-24, at 5:56 PM, Fred Kiefer  wrote:

> I thought again and I may be able to stand in as a backup mentor for your 
> project. Not the main mentor, joining in later this summer to help out. I 
> will try to register as a mentor, but you will still need an official mentor. 
> Apart for the usual candidates as Richard and Greg I would like to suggest 
> Eric and Niels. They both were excellent students at the GSoC themselves and 
> would be able to pass on that experience to other students. And they are 
> highly knowledgeable in the area.
> 
> Fred
> 
> On 24.04.2013 13:44, Ivan Vučica wrote:
>> First, thanks everyone for support and ideas!
>> 
>> On Tue, Apr 23, 2013 at 12:02 AM, Fred Kiefer  wrote:
>> 
>>> Hi Ivan
>>> 
>>> I had long ago decided that I wont mentor for GSoC this year, but your
>>> mail led me to rethink that position. Your proposal is very convincing and
>>> would be highly beneficial for GNUstep. ...
>>> 
>>> Sorry, but I wont be able to step in here. Hopefully somebody else in the
>>> GNUstep community will.
>>> 
>> 
>> Thanks!
>> 
>>> Best wishes and hope to see you in Cambridge,
>> 
>> 
>> Ditto!
>> 
>> On Tue, Apr 23, 2013 at 9:31 AM, David Chisnall  wrote:
>> 
>>> On 22 Apr 2013, at 21:43, Ivan Vučica  wrote:
>>> 
 Ping! Student registrations have started. Any prospective mentors?
>>> 
>>> I've registered as a mentor.  I'd also be most interested in the back end
>>> being refactored to support using Opal.
>>> 
>> 
>> Based on feedback everyone gave, yes, the importance of this (and the
>> importance of integration with Core Animation) seems to be the consensus.
>> 
>> Currently, basic idea that I have is to copy the entire Cairo backend (or
>> maybe use derived classes, although long-term that seems a bad idea) and
>> ensure that every Cairo surface is instead backed with an Opal context. I'd
>> temporarily expose the Cairo surface from the Opal context, and ensure that
>> calls are directed to the Cairo surface backing the Opal context instead of
>> to the Cairo surface inside the backend.
>> 
>> Then, I'd be removing the Cairo surface from the backend and replacing
>> Cairo calls with Opal calls.
>> 
>> Finally, I would be continuously looking at options for integrating Core
>> Animation with AppKit (based on feedback).
>> 
>> I'll probably need more supervision compared to implementation of UIKit,
>> but this is definitely a more useful long-term project for GNUstep.
>> 
>> I'll put together a proposal, register it on GSoC's Melange, and also send
>> it to the mailing list.
> 
> 
> ___
> 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: Arrow of NSMenu

[Eric Wasylishen]

Hi Fred,

On 2013-04-06, at 9:03 AM, Fred Kiefer  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  
>> 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: Arrow of NSMenu

[Eric Wasylishen]

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  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: Cambridge Hackathon

[Eric Wasylishen]

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  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

[Eric Wasylishen]

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  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

[Eric Wasylishen]

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  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 :
> 
>> 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

[Eric Wasylishen]

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  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

[Eric Wasylishen]

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: Couple of problems with current SVN

[Eric Wasylishen]

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

[Eric Wasylishen]

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 
> 
> 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

[Eric Wasylishen]

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  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

[Eric Wasylishen]

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  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

[Eric Wasylishen]

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" 
> :
> 
>> 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

[Eric Wasylishen]

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"  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

[Eric Wasylishen]

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

[Eric Wasylishen]

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...

[Eric Wasylishen]

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

[Eric Wasylishen]

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  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:
>  NAME:NSRangeException REASON:Index -1 is
> out of range 1 (in 'objectAtIndex:') INFO:{Array = (" 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: setlocale() [Was: Re: NSNumberFormater test fails]

[Eric Wasylishen]

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  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.)
>>> 
>

Re: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.m

[Eric Wasylishen]

tain
gdnc, gpbs, etc. are all up to date.

--Eric


On Mon, Feb 27, 2012 at 2:08 PM, Richard Frith-Macdonald
 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=gap&view=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: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.m

[Eric Wasylishen]

>> 
>> 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: > 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?
> 
> Yes, I already fixed this to use a new archive format with variable length 
> array counts.  Looks like the old archive format has had this bug practically 
> forever (fixed, system-dependent size of array counts) ... which is really 
> disappointing given than quite an effort was make to ensure that all the 
> archiving of actual values was safe across systems with different  word sizes 
> etc.
> 
Great, thanks!

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=gap&view=markup

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?

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

[Eric Wasylishen]

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=34822&view=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:  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: setlocale() [Was: Re: NSNumberFormater test fails]

[Eric Wasylishen]

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, ""); w

Re: setlocale() [Was: Re: NSNumberFormater test fails]

[Eric Wasylishen]

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  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 Bidi  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 Bidiwrote:
> 
> On Sat, Jan 21, 2012 at 10:41 AM, Fred Kiefer  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-d

Re: cursor issues in gworkspace

[Eric Wasylishen]

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: "more" icon in toolbars

[Eric Wasylishen]

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: GNUstep Code Freeze

[Eric Wasylishen]

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

[Eric Wasylishen]

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  

* 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  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: GNUstep Code Freeze

[Eric Wasylishen]

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: OpenGL context without AppKit

[Eric Wasylishen]

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: QuartzCore and Opal

[Eric Wasylishen]

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: Ugly flickering in some views

[Eric Wasylishen]

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: Ugly flickering in some views

[Eric Wasylishen]

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: Dialog display problem (Re: GNUstep Code Freeze)

[Eric Wasylishen]

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: Dialog display problem (Re: GNUstep Code Freeze)

[Eric Wasylishen]

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
> 
> ___
> 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

[Eric Wasylishen]

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  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: gui patch for review: -[NSView setBounds*:] - remove setNeedsDisplay: YES calls

[Eric Wasylishen]

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
>>> 
>>> 
>> 
> 

___
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

[Eric Wasylishen]

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
>> 
>> 
> 

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Ugly flickering in some views

[Eric Wasylishen]

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  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

Re: Ugly flickering in some views

[Eric Wasylishen]

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: gui patch for review: -[NSView setBounds*:] - remove setNeedsDisplay: YES calls

[Eric Wasylishen]

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
> 
> 

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GNUstep Code Freeze

[Eric Wasylishen]

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 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.
>>>> 
>>>> 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

[Eric Wasylishen]

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 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.
>>> 
>>> 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

[Eric Wasylishen]

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  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

gui patch for review: -[NSView setBounds*:] - remove setNeedsDisplay: YES calls

[Eric Wasylishen]

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
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

[Eric Wasylishen]

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… :-)
> 
> 
> 
> 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" 
>>  wrote: 
>> 
>>> 
>>> On Monday, January 16, 2012 16:50 CET, "Sebastian Reitenbach" 
>>>  wrote: 
>>> 
>>>> 
>>>> On Monday, January 16, 2012 16:02 CET, Fred Kiefer  
>>>> 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: Vespucci doesn't show images anymore

[Eric Wasylishen]

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
Description: Binary data


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" 
>  wrote: 
> 
>> 
>> On Monday, January 16, 2012 16:50 CET, "Sebastian Reitenbach" 
>>  wrote: 
>> 
>>> 
>>> On Monday, January 16, 2012 16:02 CET, Fred Kiefer  
>>> 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

[Eric Wasylishen]

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 Drag&Drop 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

X11 scroll-wheel improvements

[Eric Wasylishen]

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. :-)
-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

[Eric Wasylishen]

Hi Philippe,

> And there is a duplicate #import 

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

[Eric Wasylishen]

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: Slow application startup when using a theme

[Eric Wasylishen]

>> 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

[Eric Wasylishen]

Hi,
Thanks for the report, Philippe; this is indeed a fairly serious problem. :-(

> 
> 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.


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.


How about adding caching to NSBundle? It already caches the budle info.plist, 
why not the directory listing of the resource directory?

Also, it might be nice if NSBundle would have a private method:
-(NSArray*)pathsForResource: (NSString*)name ofTypes: (NSArray*)types;

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.

Eric



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Open/Save panel issue

[Eric Wasylishen]

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 
>  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

[Eric Wasylishen]

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

[Eric Wasylishen]

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

[Eric Wasylishen]

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 
beha

Re: preview: new macports ports

[Eric Wasylishen]

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:

> 


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: preview: new macports ports

[Eric Wasylishen]

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 "
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 .
> 
> :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 
> :info:build   ^
>  
> I have also attached the log file. 
> 
> On Fri, Nov 18, 2011 at 20:18, Ivan Vučica  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  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
> 
> 
> 

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: preview: new macports ports

[Eric Wasylishen]

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

[Eric Wasylishen]

> 
> 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: Next GNUstep release?

[Eric Wasylishen]

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

[Eric Wasylishen]

> 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: preview: new macports ports

[Eric Wasylishen]

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

[Eric Wasylishen]

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  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

[Eric Wasylishen]

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

Re: migration to CGFloat for NSColor?

[Eric Wasylishen]

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

migration to CGFloat for NSColor?

[Eric Wasylishen]

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: cairo x11 surfaces

[Eric Wasylishen]

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
> 
> 



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: cairo x11 surfaces

[Eric Wasylishen]

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

Re: cairo x11 surfaces

[Eric Wasylishen]

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

[Eric Wasylishen]

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

Re: Opal, CGLayer and OpenGL in UIKit

[Eric Wasylishen]

On 2011-09-30, at 11:00 AM, David Chisnall wrote:

> On 30 Sep 2011, at 17:48, Ivan Vučica wrote:
> 
>> Hi,
>> 
>> I've been reading the Apple docs on Quartz/CoreGraphics, and I've stumbled 
>> upon CGLayer. Upon first look, it looks like CGLayer is already implemented.
>> 
>> My first thought is that perhaps we don't need to actually use OpenGL when 
>> implementing UIKit, at least not initially. What do you guys think?
> 
> CGLayer is implemented, but it currently only does the very basic stuff.  It 
> currently uses a Cairo pattern to allow it to be composited.  This works, but 
> it's going to be fairly slow.

Right - but there's no need for my CGLayer implementation be slower than Quartz 
- it's all up to cairo. It's worth looking into the cairo gl backend (not 
released yet, afaik) - I've never tried it. I believe cairo is designed in such 
a way so that cairo backends can easily provide fast paths for things like 
drawing a source surface onto a destination.

>  UIKit (and modern AppKit) do a lot more.  For example, even the very basic 
> swoosh effect as you slide a layer off the screen is going to require 
> compositing the texture a few dozen times.  This can be very fast in OpenGL, 
> but is likely to be slow with Cairo.  CoreAnimation wants to move layers 
> around in 3D space (well, rotate them in 3D, move them in 2D), while 
> CoreImage wants to run shader programs on them.  All of these things are 
> trivial with OpenGL, but very hard in Cairo.
> 
> So, in theory it's possible, but in practice it will be hard.
> 

On another topic, Ivan, did you look in to http://chameleonproject.org/? I 
remember it was discussed before here. Personally, I think it would be cooler 
to further develop gnustep-gui and integrate opal (and maybe write a core 
animation implementation) such that chameleon can run on GNUstep, rather than 
write another uikit implementation. 

Cheers
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

[Eric Wasylishen]

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  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

Shal we do a gui code freeze?

[Eric Wasylishen]

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

gnustep-howto documentation update

[Eric Wasylishen]

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

[Eric Wasylishen]

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

Re: Problem with compile

[Eric Wasylishen]

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 
#include 

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 
> #import 
> 
> /* 
>  * 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  
> wrote:
> Hey,
> To use NSLog, NSString, and even constant strings (@""), you need to import 
> the GNUstep base headers.
> Adding:
> 
> #import 
> 
> 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

[Eric Wasylishen]

Hey,
To use NSLog, NSString, and even constant strings (@""), you need to import the 
GNUstep base headers.
Adding:

#import 

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