Re: -draggedImageLocation giving incorrect results?
Michael Gardner wrote: On 4/28/07, Fred Kiefer [EMAIL PROTECTED] wrote: Do you mean 0.11 as the latest release that was still fine? The current release is now 0.12 and there aren't any big differences between trunk and that release. Ah, I wasn't aware that 0.12 had been released. I was talking about 0.11. I can install 0.12 if that would help, but if there are so few changes in trunk then it doesn't seem necessary. Yes, stay with trunk, if you don't have any specific problems with it. Which value are you using for the default setting GSX11HandlesWindowDecorations? That is, is GNUstep handling the window decoration itself? I would expect so, otherwise it will be hard to explain the result you are seeing. I need to set this myself to see if I am able to reproduce the problem. I haven't modified that setting, so presumably it's still at its default value. How can I verify this? Have a look at your GNUstep defaults file. Mine is ~/GNUstep/Defaults/.GNUstepDefaults. There look out for GSX11HandlesWindowDecorations, but this setting may also have the alternative name GSBackHandlesWindowDecorations. The default value is YES, resulting in X handling the window decorations. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Themeing
Hi Christopher,
there is a small but very annoying problem with your patch for gui: You
added some clean up of he formatting to it. Now it is great to replace
the tab characters that went into the files with spaces. After noticing
that my editor used tabs instead of spaces for indentation I switched
that off and started to clean up files myself, each time I do a commit
on GNUstep. But having to proofread a huge patch with mostly whitespace
changes is rather boring. It is too easy to miss out on the important
bits, while skipping over the formatting changes.
Also your indentation does not match with the formatting rules for
GNUstep. You use
if (XXX)
{
[AAA bb];
}
whereas GNUstep has
if (XXX)
{
[AAA bb];
}
(There are other differences as well, but this is the most prominent)
Could you please switch over to the GNUstep style before doing a huge
commit?
For the changes to the comments, I also don't see why the reformatting
was necessary.
As much as I like some of the stuff you did with the Windows themes, in
the current form this patch is not ready for a review.
Have your thought about moving your NSColor code into a separate
application that will just change the system colour list and write it
out? Your code is great for most cases, but when somebody tries to
access the system colour list the result will be totally different.
The theming extensions for menu and scrollers are surely something we need.
To make your live easier in the future I will submit a whitespace change
to NSButtonCell and NSMenuItemCell removing all the tab characters.
Cheers,
Fred
Christopher Armstrong wrote:
Hi
I've been playing around with our theming API (GSTheme) with the intent
of fleshing it out a bit further. In order to confirm the style of
programmatic API I've been using, I have been trying to integrate
Windows uxtheme with the API in order to demonstrate it that it is
possible.
For those who are interested in what is happening, and are running
GNUstep on Windows XP or Vista, please look at:
http://carmstrong.fastmail.com.au/gnustep-gui-themeing-20070429.diff
http://carmstrong.fastmail.com.au/win32theme.tgz
The first is a patch that should be applied against the current
gnustep-gui SVN (don't use your working copy as this patch is not by any
means complete). It gives a (partial) API for theming menus and
scrollbars, on top of the existing buttons themeing.
The second file is a bundle that compiles to a theme. It links against
uxtheme so you will need at least Windows XP (I've only tested against
Windows Vista however) and uses code that is private and specific to the
win32/winlib backend.
I'm putting this up as a point of discussion. Comments and suggestions
are welcome.
Regards
Chris
carmstrong at fastmail dot com dot au
___
Discuss-gnustep mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Themeing
Fred Kiefer wrote:
Hi Christopher,
there is a small but very annoying problem with your patch for gui: You
added some clean up of he formatting to it. Now it is great to replace
the tab characters that went into the files with spaces. After noticing
that my editor used tabs instead of spaces for indentation I switched
that off and started to clean up files myself, each time I do a commit
on GNUstep. But having to proofread a huge patch with mostly whitespace
changes is rather boring. It is too easy to miss out on the important
bits, while skipping over the formatting changes.
Also your indentation does not match with the formatting rules for
GNUstep. You use
if (XXX)
{
[AAA bb];
}
whereas GNUstep has
if (XXX)
{
[AAA bb];
}
(There are other differences as well, but this is the most prominent)
Could you please switch over to the GNUstep style before doing a huge
commit?
For the changes to the comments, I also don't see why the reformatting
was necessary.
Sorry, the reformatting is an accidental part of me writing code or
possibly my editor (I'm using VIM with tabs set to be expanded to
spaces: sw=2, cin, expandtab, ai, sta - which one do I turn off?). I'll
definitely fix it up for next time. I didn't intend this patch to be
committed to SVN or even reviewed as such; I attached it as an example
of what I've done so that people could try it out. I know it is a mess
and thats why I suggest you apply it against a temporary SVN checkout to
save messing up your working copy.
As much as I like some of the stuff you did with the Windows themes, in
the current form this patch is not ready for a review.
Have your thought about moving your NSColor code into a separate
application that will just change the system colour list and write it
out? Your code is great for most cases, but when somebody tries to
access the system colour list the result will be totally different.
Yep, this is currently a hack. I need a way to map the GetSysColor()
function to the NSColor system APIs, but the theming API only accepts
static NSColorLists. I might try and expand something out to permit
themes to specify a color list on the fly.
The theming extensions for menu and scrollers are surely something we need.
To make your live easier in the future I will submit a whitespace change
to NSButtonCell and NSMenuItemCell removing all the tab characters.
Does this mean you are going to commit part of this patch, or would you
like me to split it out first so you can get part of it in?
Regards
Chris
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Themeing
Hi Turns out that svn diff command can be told to ignore whitespace changes. This patch is alot smaller and contains the useful changes. I don't know if it works. http://carmstrong.fastmail.com.au/gnustep-gui-themeing-20070429-2.diff cid:part1.03010907.0601@fastmail.com.au Regards Chris ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Themeing
On Sun, Apr 29, 2007 at 09:43:26PM +1000, Christopher Armstrong wrote: Fred Kiefer wrote: Sorry, the reformatting is an accidental part of me writing code or possibly my editor (I'm using VIM with tabs set to be expanded to spaces: sw=2, cin, expandtab, ai, sta - which one do I turn off?). I'll definitely fix it up for next time. I didn't intend this patch to be committed to SVN or even reviewed as such; I attached it as an example of what I've done so that people could try it out. I know it is a mess and thats why I suggest you apply it against a temporary SVN checkout to save messing up your working copy. When I'm working on GNUstep code, the best settings I've found are: set ts=8 set sts=2 set sw=2 set noet set nocopyindent In fact, I have this in my .vimrc: com! -nargs=0 Gnustep setlocal ts=8 | \ setlocal sw=2 | \ setlocal sts=2 | \ setlocal noet | \ setlocal nocopyindent Then when I start with a GNUstep file, I can just run :Gnustep and be up and going with the right settings. - Andy -- Andrew Ruder [EMAIL PROTECTED] http://www.aeruder.net ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Themeing
Christopher Armstrong wrote:
Fred Kiefer wrote:
Hi Christopher,
there is a small but very annoying problem with your patch for gui: You
added some clean up of he formatting to it. Now it is great to replace
the tab characters that went into the files with spaces. After noticing
that my editor used tabs instead of spaces for indentation I switched
that off and started to clean up files myself, each time I do a commit
on GNUstep. But having to proofread a huge patch with mostly whitespace
changes is rather boring. It is too easy to miss out on the important
bits, while skipping over the formatting changes.
Also your indentation does not match with the formatting rules for
GNUstep. You use
if (XXX)
{
[AAA bb];
}
whereas GNUstep has
if (XXX)
{
[AAA bb];
}
(There are other differences as well, but this is the most prominent)
Could you please switch over to the GNUstep style before doing a huge
commit?
For the changes to the comments, I also don't see why the reformatting
was necessary.
Sorry, the reformatting is an accidental part of me writing code or
possibly my editor (I'm using VIM with tabs set to be expanded to
spaces: sw=2, cin, expandtab, ai, sta - which one do I turn off?). I'll
definitely fix it up for next time. I didn't intend this patch to be
committed to SVN or even reviewed as such; I attached it as an example
of what I've done so that people could try it out. I know it is a mess
and thats why I suggest you apply it against a temporary SVN checkout to
save messing up your working copy.
As much as I like some of the stuff you did with the Windows themes, in
the current form this patch is not ready for a review.
Have your thought about moving your NSColor code into a separate
application that will just change the system colour list and write it
out? Your code is great for most cases, but when somebody tries to
access the system colour list the result will be totally different.
Yep, this is currently a hack. I need a way to map the GetSysColor()
function to the NSColor system APIs, but the theming API only accepts
static NSColorLists. I might try and expand something out to permit
themes to specify a color list on the fly.
The theming extensions for menu and scrollers are surely something we
need.
To make your live easier in the future I will submit a whitespace change
to NSButtonCell and NSMenuItemCell removing all the tab characters.
Does this mean you are going to commit part of this patch, or would you
like me to split it out first so you can get part of it in?
No, at least not now, I will be away for the next ten days.
Fred
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Application crashes when embedding GNU Smalltalk lib - Help?
Does anyone happen to know why the mere presence of "-lgst" (GNU Smalltalk library) in the link would cause the attached app to crash? (see transcript below)Thanks!-TimTranscript:% uname -aFreeBSD kashyyyk.astro.net 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 11:05:30 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP i386### NOTE: As shown below, app runs when -lgst is suppressed; same results if the Test_GUI_LIBS line is simply removed from the Makefile: ###% gmake Test_GUI_LIBS=This is gnustep-make 2.0.0. Type ’make print-gnustep-make-help’ for help.Making all for app Test... Creating Test.app/ Compiling file main.m ... Linking app Test ... Creating Test.app/Resources... Creating Test.app/Resources/Info-gnustep.plist... Creating Test.app/Resources/Test.desktop...% openapp ./Test2007-04-29 19:33:45.080 Test[80416] Unable to read color file at "/Network/Users/tmcintos/Library/Colors/Emacs.clr" -- unknown format.^C% gmake cleanThis is gnustep-make 2.0.0. Type ’make print-gnustep-make-help’ for help.rm -rf ./*~ ./obj(cd .; \ rm -rf *.app)### NOTE: Here is the build with -lgst where the crash is observed: ###% gmakeThis is gnustep-make 2.0.0. Type ’make print-gnustep-make-help’ for help.Making all for app Test... Creating Test.app/ Compiling file main.m ... Linking app Test ... Creating Test.app/Resources... Creating Test.app/Resources/Info-gnustep.plist... Creating Test.app/Resources/Test.desktop...% openapp ./TestSegmentation fault% debugapp ./TestGNU gdb 6.1.1 [FreeBSD]Copyright 2004 Free Software Foundation, Inc.GDB is free software, covered by the GNU General Public License, and you arewelcome to change it and/or distribute copies of it under certain conditions.Type "show copying" to see the conditions.There is absolutely no warranty for GDB. Type "show warranty" for details.This GDB was configured as "i386-marcel-freebsd"...(gdb) runStarting program: /.amd_mnt/alderaan/Exports/Users/tmcintos/Development/SmallTalk/SmallStep/Test.subproj/Test.app/Testwarning: Unable to get location for thread creation breakpoint: generic error[New LWP 100098][New Thread 0x8054018 (LWP 100098)]Program received signal SIGSEGV, Segmentation fault.[Switching to Thread 0x8054018 (LWP 100098)]0x in ?? ()(gdb) bt#0 0x in ?? ()#1 0x2852fde2 in +[NSAutoreleasePool new] (self=0x28773a80, _cmd=0x28773b08) at NSAutoreleasePool.m:143#2 0x285300e4 in +[NSAutoreleasePool addObject:] (self=0x28773a80, _cmd=0x2879d208, anObj=0x80c9b60) at NSAutoreleasePool.m:247#3 0x285bbd30 in -[NSObject autorelease] (self=0x80c9b60, _cmd=0x287d6960) at NSObject.m:1790#4 0x28653a29 in +[NSString(GSCategories) stringWithFormat:arguments:] (self=0x287b2880, _cmd=0x28789f68, format=0x287b2ddc, argList=0xbfbfdc90 "x¬\t\b%") at GSCategories.m:1100#5 0x285828aa in +[NSException raise:format:arguments:] (self=0x28789d80, _cmd=0x28789f60, name=0x2878a07c, format=0x287b2ddc, argList=0xbfbfdc90 "x¬\t\b%") at NSException.m:751#6 0x28582854 in +[NSException raise:format:] (self=0x28789d80, _cmd=0x287b28e8, name=0x2878a07c, format=0x287b2ddc) at NSException.m:739#7 0x28602c39 in +[NSString initialize] (self=0x287b2880, _cmd=0x287c5408) at NSString.m:598#8 0x287edce7 in __objc_install_premature_dtable () from /usr/lib/libobjc.so.2#9 0x287ee3b0 in objc_msg_lookup () from /usr/lib/libobjc.so.2#10 0x285baca7 in +[NSObject initialize] (self=0x2879d140, _cmd=0x287c5408) at NSObject.m:1133#11 0x287edce7 in __objc_install_premature_dtable () from /usr/lib/libobjc.so.2#12 0x287edcf4 in __objc_install_premature_dtable () from /usr/lib/libobjc.so.2#13 0x287ee3b0 in objc_msg_lookup () from /usr/lib/libobjc.so.2#14 0x281a6ee1 in NSApplicationMain (argc=1, argv=0xbfbfdeb4) at Functions.m:53#15 0x0804868f in main (argc=1, argv=0xbfbfdeb4) at main.m:16(gdb) quitThe program is running. Exit anyway? (y or n) y% ldd Test.app/TestTest.app/Test: libgst.so.5 = /usr/local/lib/libgst.so.5 (0x2807a000) libgnustep-gui.so.0.13 = /System/Library/Libraries/libgnustep-gui.so.0.13 (0x28114000) libgnustep-base.so.1.15 = /System/Library/Libraries/libgnustep-base.so.1.15 (0x2847d000) libobjc.so.2 = /usr/lib/libobjc.so.2 (0x287e4000) libm.so.4 = /lib/libm.so.4 (0x287f8000) libpthread.so.2 = /lib/libpthread.so.2 (0x2880e000) libc.so.6 = /lib/libc.so.6 (0x28833000) libstdc++.so.5 = /usr/lib/libstdc++.so.5 (0x28918000) libreadline.so.6 = /lib/libreadline.so.6 (0x289e3000) libexecinfo.so.1 = /usr/local/lib/libexecinfo.so.1 (0x28a1) libaudiofile.so.0 = /usr/local/lib/libaudiofile.so.0 (0x28a1b000) libaspell.so.16 = /usr/local/lib/libaspell.so.16 (0x28a3f000) libungif.so.5 = /usr/local/lib/libungif.so.5 (0x28b0a000) libpng.so.5 = /usr/local/lib/libpng.so.5 (0x28b12000) libtiff.so.4 = /usr/local/lib/libtiff.so.4 (0x28b34000) libz.so.3 = /lib/libz.so.3 (0x28b82000) libjpeg.so.9 = /usr/local/lib/libjpeg.so.9
Re: Gnustep-base thread creation bug.
On 27 Apr 2007, at 22:56, Chris Ball wrote: Right now there appears to be a slightly subtle bug in thr-pthread.m. Specifically the threads created here are created as joinable threads, this is bad because joinable threads have to be joined before their memory is released. What we really want here are detached threads that just go away when they are done executing. This is trivial to test, create a program that spawns threads that do nothing but exit and watch as the memory usage explodes as the thread count grows (I manage around 300 threads before a cryptic message that actually means ENOMEM turns up). I think thr-pthread.m is used only on OpenBSD systems, and I don't have one to test on. I've changed the code to use _objc_thread_attribs to set the thread as not joinable in subversion trunk, and I would be grateful if you could test this and let me know if it's ok (if it is, I'll backport it to the stable branch). Looking at the code in the objc runtime library, it seems like that would heave exactly the same problem with libpthread and thr-pthread.c Do you know if that's the case? If so, do you know if it has been reported to the gcc maintainters? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Gnustep-base thread creation bug. continued.
I spent a bit of time looking at this today and realized that the way thr-pthead.m is initialized isn't exactly my problem. It turns out that my build of base is using gcc's primitives directly and not the thr-pthread.m here. This leaves me more confused as it looks like the gcc primitives should be ok but they are not. If I build a version of my test program that doesn't use the foundation class and just calls objc_thread_detach directly I am still running into the same problems. I'm still looking into things but at this point my best theories are: 1.) The current slackware's gcc is using thr-pthread instead of thr-posix which would break things since the pthread init doesn't set detachstate. 2.) The is a deeper gcc problem where either __objc_exec_class isn't being called or it isn't calling __objc_init_thread_system. Right now I'm betting on the distribution being dodgy but until I try building a new gcc or two I won't know for sure. Mind you I'm pretty sure the old linux pthread code was posix enough for this to be a problem regardless... I'll report back as I go. Chris. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
