gnustep app crash, binary incompatibility introduced yesterday/today
Hi, somehow between yesterday and today we introduced some binary incompatibility: I recompiled whole core today (the previous version I had was no more than 24-48hrs old) Ink.app/Ink Unable to set up with [NSProcessInfo-debugSet] Segmentation fault (core dumped) after recompiling Ink, everything worked. Was this intentional or did it slip in just so before release? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
Hi, Fred Kiefer wrote: Thank you for the bug report. For me this isn't a show stopper for the next GNUstep release. It only affects Windows and mostly the WinUX theme. It may be a show stopper for that theme, but we already decided not to make it the default theme on Windows. Agreed, that theme should not be a showstopper, but the standard theme should work on windows as much as possible. From my side the only know open issue is still the Gorm segmentation fault I get from time to time. As Greg seems to be unable to reproduce this, we should go ahead with the release despite of this problem. For GUI the current feature freeze is really hindering development. Does anybody disagree with that? No, but Greg should have the last word. Adam, do you think you could do the release this week? I'd very like the issue about NSToolbar crashing on SPARC being investigated abit, now that I have proven that it reproduces with the ToolbarExample and not only with Grr. Of course fixing the search field in the toolbar would be also very nice. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
Hi, If these exceptions were Uncaught exception NSInvalidArgumentException, reason: NSObject(class) does not recognize type the issue is fixed now (the latest base changes had inadvertently made GSObjCAllSubclassesOfClass return all superclasses of the class). The problem on Linux/x86 is now solved. I will check the Linux/MIPS ass soon as possible. Riccardi ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
inconsistency exception with Grr on Linux/MIPS
Hi, I am a bit clueless, I get an exception when starting Grr on Linux/MIPS (the small Letux 400). Grr works for me however on other platforms like x86 and SPARC. Also, Grr used to work on the Letux too, I still have the saved articles I read in the past. Something in the recent (2-3 weeks at most) changes in Core upset it, do you have any idea? I made a clean compilation of core, RSSKit and Grr. 2010-05-02 12:40:58.703 Grr[3607] Tree Database Component starting up... 2010-05-02 12:40:58.754 Grr[3607] Article.m:38 Assertion failed in Article(instance), method initWithDictionary:. Cannot initialise an article from the nil dictionary 2010-05-02 12:40:58.758 Grr[3607] Problem posting notification: NSException: 0x8523c8 NAME:NSInternalInconsistencyException REASON:Article.m:38 Assertion failed in Article(instance), method initWithDictionary:. Cannot initialise an article from the nil dictionary INFO:(nil) Maybe somebody can reproduce this problem on a machine were debugging is more comfortable? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: inconsistency exception with Grr on Linux/MIPS
Hi, Hi, I am a bit clueless, I get an exception when starting Grr on Linux/MIPS (the small Letux 400). Grr works for me however on other platforms like x86 and SPARC. Also, Grr used to work on the Letux too, I still have the saved articles I read in the past. Something in the recent (2-3 weeks at most) changes in Core upset it, do you have any idea? I made a clean compilation of core, RSSKit and Grr. correction: it fails now on OpenBSD/SPARC too now. And I am sure that it worked there too! Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: inconsistency exception with Grr on Linux/MIPS
Hi, I tried to look at the code to understand where the assertion comes from, but failed to understand where the Article objects actually get created. It really would help, if you could send a back trace. Most likely the whole problem comes from a corrupt file. Have you tried moving all your stored articles away Fred, I did not try, but I was wrong. Somehow the original files are not compatible on some platforms anymore. I follow the same feeds on my computers, so the articles are the same. On the small Letux, removing the articles database made the application start again. Subscribing to a feed, reading articles, reopening the application works. Something in base changed perhaps, since there were no Grr changes in the last month. Anyway, since it is coherent with itself, it is fine. On Sparc the application starts again too after removing defaults and articles DB, however other bugs show up which I report separately. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: inconsistency exception with Grr on Linux/MIPS
Hi I tried to look at the code to understand where the assertion comes from, but failed to understand where the Article objects actually get created. It really would help, if you could send a back trace. Most likely the whole problem comes from a corrupt file. Have you tried moving all your stored articles away? I removed everything, started the application subscribed to a feed (I performed the same operation on LInux/MIPS without troubles) but on quit of the applicaiton I get a crash which I do not get on other platforms. Could be this a Grr issue hidden on other platforms? Or even a core issue? Program received signal SIGBUS, Bus error. objc_msg_lookup (receiver=0x9c7250ff, op=0xec59b78) at sendmsg.c:224 224 result = sarray_get_safe (receiver-class_pointer-dtable, (gdb) bt #0 objc_msg_lookup (receiver=0x9c7250ff, op=0xec59b78) at sendmsg.c:224 #1 0x0e89f918 in -[NSWindow dealloc] () from /usr/GNUstep/System/Library/Libraries/libgnustep-gui.so.0.17 #2 0x0d3944c8 in -[NSObject release] () from /usr/GNUstep/System/Library/Libraries/libgnustep-base.so.1.19 #3 0x0e72a654 in -[NSApplication dealloc] (self=0xc9aa388, _cmd=0xd73b2b4) at NSApplication.m:1220 #4 0x0d3944c8 in -[NSObject release] () from /usr/GNUstep/System/Library/Libraries/libgnustep-base.so.1.19 #5 0x0e7306dc in -[NSApplication replyToApplicationShouldTerminate:] ( self=0xc9aa388, _cmd=0xe8b45f8, shouldTerminate=1 '\001') at NSApplication.m:3459 #6 0x0e73041c in -[NSApplication terminate:] (self=0xc9aa388, _cmd=0xec765f0, sender=0x8a53a88) at NSApplication.m:3412 #7 0x0e72d228 in -[NSApplication sendAction:to:from:] (self=0xc9aa388, _cmd=0xec2b434, aSelector=0xec765f0, aTarget=0x0, sender=0x8a53a88) at NSApplication.m:2193 #8 0x0e7e98d4 in -[NSMenu performActionForItemAtIndex:] () from /usr/GNUstep/System/Library/Libraries/libgnustep-gui.so.0.17 #9 0x0e7f1b4c in -[NSMenuView trackWithEvent:] (self=0x90b9108, _cmd=0x8a52d08, event=0x8a53e88) at NSMenuView.m:1642 #10 0x0e7f1cb4 in -[NSMenuView mouseDown:] (self=0x90b9108, _cmd=0xec5ac20, theEvent=0x8a52d08) at NSMenuView.m:1687 #11 0x0e8a9d0c in -[NSWindow sendEvent:] () from /usr/GNUstep/System/Library/Libraries/libgnustep-gui.so.0.17 #12 0x0e72cc94 in -[NSApplication sendEvent:] (self=0xc9aa388, _cmd=0xebfdba0, theEvent=0x8a52d08) at NSApplication.m:2068 #13 0x0e72b594 in -[NSApplication run] (self=0xc9aa388, _cmd=0xebf65d8) at NSApplication.m:1530 #14 0x0e70d32c in NSApplicationMain (argc=202182728, argv=0xf7ff80d4) at Functions.m:74 #15 0x0001661c in gnustep_base_user_main () #16 0x0d3c41f0 in main (argc=1, argv=0xf7ff80d4, env=0xf7ff80dc) at NSProcessInfo.m:910 #17 0x00011ab4 in ___start () #18 0x000119e0 in _start () #19 0x000119e0 in _start () Previous frame identical to this frame (corrupt stack?) It seems to me an action is NIL and this causes a crash on SPARC. I rememebr some limitations there regarding NIL objects. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
Hi, There hasn't been much progress over the last week. More bugs got reported than fixed over that time. We can either make a release now, with a lot of known issues, even some that weren't there a few weeks ago. Or delay the release indefinitely. Not fixed doesn't mean that it is not important. Perhaps some persons did not have time? Or perhaps some persons were not able to understand and fix the problems they found (like in my case?) Most of the newly reported bugs are for the Windows platform, which we didn't support that well on previous releases. Even with all this issues GNUstep is a lot more stable there then it used to be. Agreed, but smoothing out some stuff here and there On my laptop today I cannot start *any* application even after a full, clean build of core. On my letux Grr throws exceptions. On both machines things worked enough to be of daily use about 1-2 months ago... Of all the other newly reported bugs (and I regard the bug tracker as the definite list here) only the one I found yesterday looks like a show stopper to me. If the NIB loading changes in gui really broke Gorm, then we have to fix that before a release. Greg, could you please look into this and give some feedback? Ok, so I need to put the stuff I encounter on the bugtraker. If we could get that one issue out of the way I am still all for a release. We should have had a release months ago. I'd love to have at least the toolbar issue resolved. Windows is decent for me, except the big black GWorkspace issue. I hope to gain more insight this Weekend, if not fixes, at least new information. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: compile/link problems on linux/ppc
Hi, It's a duplication of assembler labels in inline assembler code that is used more than once. I have fixed that in svn by using a local label instead of incmodified. Code duplication occurs because GSAtomicIncrement is used in NSIncrementExtraRefCount, which is a public inline function. Thus, the compiler generates the definition of NSIncrementExtraRefCount so that other files can call it. Furthermore the function's code is expanded inline where it is used in NSObject.m, namely in the -retain method. It compiled now and seems to work, thanks. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSToolbar and SearchView
Hi, It was most likely Dougs commit 30143 that broke things for you. But as you don't describe in detail what is wrong, it is hard to tell. And you must be aware of that specific fix as you corrected some C99 issues you had with it. The search panels comes up way too small. I haven't checked precisely, but I believe it just displays at its minimum size. I admit I dod not analyze Doug's change, I just mechanically fixed compiler issues. The only change you made to toolbars that I am aware of was the _isFlexibleSpace method (By the way, your test is unneeded, the method should just return NO to get the behaviour you want. This method is overriden in the subclass). And nothing in that area has changed. On the other hand all the layout code there is just a hack, I am not surprised to see it broken by unrelated changes. We should rewrite the whole area, if ever somebody has the time for that... Yes, the code is messy and complicated, but I believe after my change reasonably correct, even if limited, since it doesn't take flexible space and resizing well in account as you well know. Understandable that some change broke the code unintended. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
problems with gworkspace on windows
Hi, with the latest version of core, GWorkspace displays a big black screen and nothing more, I think there are problem displaying the desktop. Once disabled it and restarted, the viewers show. This used to work. Perhaps some of the recent changes? Can some of you reproduce? I rebuilt twice... Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
NSToolbar and SearchView
Hi, using Grr, I notice that the search component is again displayed wrong. I had fixed that (other issues remained, but they were to be considered minor and Fred knows that we have them on the table). Did someone revert or work around my fix? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
compile/link problems on linux/ppc
Hi, while compiling base on Linux/ppc32 with gcc 4.3.2 I get: Compiling file NSObject.m ... /tmp/ccwBOh8K.s: Assembler messages: /tmp/ccwBOh8K.s:8384: Error: symbol `incmodified' is already defined make[4]: *** [obj/libgnustep-base.obj/NSObject.m.o] Error 1 What could that be? A compiler error? or some problematic code which confuses the linker/compiler? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
Nicola Pero wrote: Looks like we have more commit right now during code freeze then we have at normal times. I would suggest that we give up the idea of doing more tests. As long as people cannot stick to a code freeze even for a week, I thought we were in feature freeze - ie, all commits must be bug fixes as opposed to implementation of new features. A typical pre-release phase to iron out bugs before a release. :-) Exactly! I understood the same. Of course some fixes might introduce new bugs, btu this is normal during testing. Instead, you're suggesting we're in code freeze - meaning no commits at all ? Ie, nothing gets done for weeks ? I've never seen a project do that. Anyway it would be easy enough to do, we just all have to stop doing anything. Hmmm. Not sure why that would be useful ? ;-) Never head about that, not even at work. A freeze of 1-2 days is possible there, for pure testing, but we can't in opensource do that. Or we might declare a certain weekend to be test weekend, if a couple of people can follow that. With about 150 bugs open in the bug tracking system, we probably need quite a few weeks of feature freeze / bug fixing to get a good release. :-) Yes, we have a lot of bugs. I was speaking with Gregory and it would be nice to have some of these fixed. I personally suggest we stay in a feature freeze / bug fixing only phase for a while until the bug count is down and the commits slow down because there are no more bugs to fix :-) Yes, or at least a certain number of bugs have been addressed or explained or posponed. I undertand that this release is long due, but it is a very important release I think. There are many changes, I noticed that many applications need a new release because of adjustments needed. Even smalls tuff, like the header and import cleanup done by Fred. Of course he did a good job, the applications were wrong, but they need to be released soon, so that people don't experience broken applications. There will be some sort of avalanche effect. We must be careful about that, but if done well it will give us exposure and advertisement! They can't call us dead anymore. Finally, it is quite possible you were referring to some specific changes that are new features instead of being bug fixes - presumably in the gui ? If so, you should IMO feel free to point these out, and even revert them. Some of the commits clearly marked fixes. How good they are we must retest. Cheers, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
Hi, * I also wanted to look at the Cygwin port, but that may not have time before the release. I would appreciate that. I think it is currently broken, at least for me. Somebody worked here on the list, but he never replied me when I asked how far he got. Since I consider it broken, I would not put it subject to feature freeze. If you improve it even partially (atl least to get base working) go on. A very very nice feature fix would be having the instalaltion domain configuration working on windows like on linux! I bet Gregory agrees... Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Which bugs to focus on for the release?
Hi, I don't think the problem is the explanation, it's that -core and -system seem to be meaningless names. Maybe renaming -system to either -dependencies or -development would make sense? Neither of those make sense to me though. -system is the package that contains all the required system components to run GNUstep on a windows machine, such as graphics libraries, a shell, Msys, MingW dlls, etc. -core is just the basic core libraries from GNUstep. There's already a -devel package that is developer related files (svn, autoconf, ssh) I think your names make sense. Especially, core is indeed core and relates to our core libraries. The only name which was not totally clear to me at first was system. I now perfectly understand that it is the msys part and afterward I understand it. Maybe we could call it msys-system. I think it makes sense also for future releases where I will expect more frequent releases of core, where theoretically msys-system will be more stable. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: opening problems with GWorkspace
Hi, 1) when using gopen xxx NSworkspace will launch also gworkspace automatically. Strangely, GWorkspace now opens and asks you are you sure you want to quit ?... 2) gopen GWorkspace will open a double copy of it causing grief!!! Could you be more specific what the problem here is? As far as I understand it NSWorkspace has always relied on a workspace application to do most of the work. GWorkspace being the default one. Correct. gopen just uses this mechanism to get it's job done. So yes, starting GWorkspace via gopen could result in it being started twice. No gnustep application should be open twice as far as I can understand... The only thing you report that seems strange is that GWorkspace will quit again. This sounds more like an GWorkspace issue. Possibly, but it did not happen in the past. It does not quit in the sense crash. It asks me politely like I selected Quit from the menu! Nobody else noticed that? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Which bugs to focus on for the release?
Hi, Gregory Casamento wrote: Have we established a list of bugs we would like to be fixed prior to the release? I'd like to get a consensus about this before we do it. Fred has a small app which exemplifies breakages in the different backends with regarding rects stroked and filled. We did it during LindauStep. Fred do you think you could fix them for this release? Thank you, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
opening problems with GWorkspace
Hi, after the core release, I will do a maintenance release of GWorkspace (since the old one would not compile anyway, causing frustration among the users). I noticed some strange behaviour with the opening of GWorkspace, which did not happen before. Maybe a change in base which needs some improvement or which requires GWorkspace adaptation. 1) when using gopen xxx NSworkspace will launch also gworkspace automatically. Strangely, GWorkspace now opens and asks you are you sure you want to quit ?... 2) gopen GWorkspace will open a double copy of it causing grief!!! Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Which bugs to focus on for the release?
Hi The switch to cairo as the default backend was a step that I should have done right after the last release. Doing so now is just not advisable. Or is it? I think not, libart should stick for this release, cairo will be for the next. Cairo has some problems here and there, although it is reasonably usable for the day usage. For example cairo has troubles with displaying (big) images, it can suddenly say it cannot allocate shared memory and then gets slooowww Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Some apps issues
Hi German, German Arias wrote: I have latest versions. But, after try many times. I found the problem only when you select Scale to fit before load images. I was able to reproduce the problem, thanks. It should be fixed in current CVS. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
Hi I haven't kept up with the state of development/readiness of the windows theme, but I really don't agree with forcibly changing the default theme ... I know it makes me really irate on the odd occasion when Apple change default behaviors on OSX, and I have to look for the way to revert to previous behaviors. The theme is the user's choice ... so what should happen is that, on installation, the installer should ASK the user which theme they want to use, allowing them to select between available themes, but making the windows one the first selection (assuming here that for most apps it works well ... people can always change theme on a per-app basis anyway). If the user has already chosen a theme themselves (ie the default is already set in NSGlobalDomain) then the theme that they had previously chosen should be the first/default option when they are asked to choose a default theme ... so they can just hit the return key to continue using the last theme they selected. Although I generally agree with leaving the default theme as is on Unix, where we can theoretically strive for a complete environment, on Windows we always will be hosted, thus I consider it correct to have a more windows. friendly theme as the default on windows. I consider it an exception. Even when using a complete development environment you probably want that. Also, if you go as far as having several developer applications installed, you will be smart enough to be able to revert to the default theme if you wish. A default theme however must guarantee that any application can be compiled and work well without any further porting efforts to adapt it. This is not the case with the current WinUXTheme, although it works very well for some applications. I think a good proposal would be, if possible, to make the WinUXTheme as a user-selectable component in the NSIS installer, however selecting it should write automatically the global preferences so that it will be enabled. In this release I would make it by default unselected and maybe the next release will have it selected by default. I don't know however if the windows installer can be so smart to write the NSGlobalDomain when installing it? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
Hi, yes I find it due, we spoke about that before Fosdem indeed! This time we should really stabilize ad decide that for a period of a fortnight (or longer if deemed needed) where only bugfixes are commited! Not changes to the runtime or other far-reaching things. Also, fixes may produce bugs and need to be refixed. The changes introduced were extremely huge and their effect is just now stabilizing. Currently, the core systems compiles on most platforms I have available, spanning from gcc 2.95 to gcc 4.4 and from sparc to MIPS. Recently I even got GNU/Hurd compiling! Linux, FreeBSD, OpenBSD, Windows compile. However, there are bugs and problems. For example, I'm unable to start anything on Hurd because gdomap/gdnc seem to have problems. GWorkspace crashes everywhere (which it didn't up to a month ago about). Also GWorkspace now has strange problems. I think it would be also good to check our bug list and see if a couple of those bugs should be fixed with the release. Given the recent surge of interest in Windows, I hope that Adam will also prepare a Windows release (I would suggest based on gcc/objc1, but possibly supporting clang/objc2 too). And let's make that a good release! After this release, I'd like Richard release a new version of GSWS and I will release an application based on it to the public. So let's check the details! Riccardo Fred Kiefer wrote: Before FOSDEM we were planing a coordinated release of the GNUstep core components. In the meantime a lot has happened. Base was completely rewritten, or so it seems from the outside and gui had to play catch up. Then I toyed around with the NIB loading and broke a few things. Now things are rather stable again and we should come back to our original plan. For gui this would be an intermediate release not the 1.0 release I am hoping to see later this year. What still needs to be done in gui is finishing the switch to #import, moving on to non fragile ivars will happen later. I first want to see the results base gets with its approach to that topic. Adam, could you once more take up the task of releasing GNUstep? We should give it another week or two so that people can complain about existing bugs that need to be fixed before the release. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
gcc version and declaration-after-statement
Hi, what gcc version is -Wdeclaration-after-statement enabled for? I know it works for the gcc 4. series, it doesn't for 2.95. On one of my lesser-used computers I have gcc 3.3.2 and it is not supported. Could it please be disabled? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
Hi, Additionally, for the Windows packages the default theme should be the WinUXTheme and not the NeXT theme on that system. Completely agree. I heartily disagree, even if I am the one that started working on it after the hiatus of Christopher and Fred! I understand all the pressure Greg wants, but I still think it is not ready. The apps he thinks about work, but not the one I want to release, one of which I want to release well doesn't. If the application doesn't come up with a main window, the menus have troubles, or if it doesn't open an untitled document (same problem). Several others apps do work, but are very ugly. Possible solutions were discussed, but none implemented yet. Also ideas about directly with the app plist were put on the table. Right now it is too early, I propose to ship it together with system preferences, easy to enable, but not yet default. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
GWorkspace crash
Hi, the recent changes, make GWorkspace crash or hang. I get a crash on FreeBSD if I try to close one of the viewer windows: #0 0x288e3a64 in objc_msg_lookup () from /usr/lib/libobjc.so.3 #1 0x282a231f in -[NSApplication(Private) _targetForAction:keyWindow:mainWindow:] (self=0x29046948, _cmd=0x284d2ab8, aSelector=0x290adde8, keyWindow=0x0, mainWindow=0x2c4f9908) at NSApplication.m:3814 #2 0x282a22e2 in -[NSApplication(Private) _targetForAction:keyWindow:mainWindow:] (self=0x29046948, _cmd=0x284d2ab8, aSelector=0x290adde8, keyWindow=0x2c4fa008, mainWindow=0x2c4f9908) at NSApplication.m:3841 #3 0x282a1833 in -[NSApplication targetForAction:] (self=0x29046948, _cmd=0x284d2ac0, aSelector=0x290adde8) at NSApplication.m:2251 #4 0x282a3708 in -[NSApplication targetForAction:to:from:] (self=0x29046948, _cmd=0x285203d0, theAction=0x290adde8, theTarget=0x0, sender=0x29b79ce8) at NSApplication.m:2236 #5 0x283614d5 in -[NSMenu update] (self=0x299cae88, _cmd=0x285202e0) at NSMenu.m:1150 #6 0x283617a2 in -[NSMenu update] (self=0x2998a548, _cmd=0x284d2988) at NSMenu.m:1145 #7 0x282a50c2 in -[NSApplication(Private) _windowDidBecomeKey:] ( self=0x29046948, _cmd=0x284d2838, notification=0x293a19e8) at NSApplication.m:3890 #8 0x287181ce in -[NSNotificationCenter _postAndRelease:] (self=0x29075fc8, _cmd=0x28881968, notification=0x293a19e8) at NSNotificationCenter.m:1161 #9 0x287173f8 in -[NSNotificationCenter postNotificationName:object:userInfo:] (self=0x29075fc8, _cmd=0x28881970, name=0x28581804, object=0x2c4fa008, at NSControl.m:713 #10 0x2871726e in -[NSNotificationCenter postNotificationName:object:] ( self=0x29075fc8, _cmd=0x28572908, name=0x28581804, object=0x2c4fa008) at NSNotificationCenter.m:1200 #11 0x2841e3df in -[NSWindow becomeKeyWindow] (self=0x2c4fa008, _cmd=0x28572948) at NSWindow.m:1486 #12 0x28418764 in -[NSWindow makeKeyWindow] (self=0x2c4fa008, _cmd=0x28572438) at NSWindow.m:1600 #13 0x284200a8 in -[NSWindow(GNUstepPrivate) _lossOfKeyOrMainWindow] ( self=0x2c4f9908, _cmd=0x28572988) at NSWindow.m:294 #14 0x2841b149 in -[NSWindow orderWindow:relativeTo:] (self=0x2c4f9908, _cmd=0x28572978, place=NSWindowOut, otherWin=0) at NSWindow.m:1701 #15 0x28418498 in -[NSWindow orderOut:] (self=0x2c4f9908, _cmd=0x28572b10, sender=0x2c4f9908) at NSWindow.m:1655 #16 0x2842031a in -[NSWindow close] (self=0x2c4f9908, _cmd=0x28572ba0) at NSWindow.m:2689 #17 0x28426ef8 in -[NSWindow performClose:] (self=0x2c4f9908, _cmd=0x28572bf8, sender=0x2c4c9038) at NSWindow.m:2911 #18 0x282a18d2 in -[NSApplication sendAction:to:from:] (self=0x29046948, _cmd=0x284f5848, aSelector=0x28572bf8, aTarget=0x2c4f9908, sender=0x2c4c9038) at NSApplication.m:2193 #19 0x283028f4 in -[NSControl sendAction:to:] (self=0x2c4c9038, _cmd=0x284e7100, theAction=0x28572bf8, theTarget=0x2c4f9908) #20 0x282dc3e4 in -[NSCell _sendActionFrom:] (self=0x2c4ecb88, _cmd=0x284e7150, sender=0x2c4c9038) at NSCell.m:1437 #21 0x282e1f6a in -[NSCell trackMouse:inRect:ofView:untilMouseUp:] ( self=0x2c4ecb88, _cmd=0x284f58e8, theEvent=Variable theEvent is not available. ) at NSCell.m:1755 #22 0x283025c0 in -[NSControl mouseDown:] (self=0x2c4c9038, _cmd=0x28572dc8, theEvent=0x2936eba8) at NSControl.m:869 #23 0x28425f28 in -[NSWindow sendEvent:] (self=0x2c4f9908, _cmd=0x284d2a60, theEvent=0x2936eba8) at NSWindow.m:3675 #24 0x282a51b2 in -[NSApplication sendEvent:] (self=0x29046948, _cmd=0x284d2990, theEvent=0x2936eba8) at NSApplication.m:2068 #25 0x282a6e8e in -[NSApplication run] (self=0x29046948, _cmd=0x80f4cd0) at NSApplication.m:1530 #26 0x0804d50b in main () at main.m:37 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
problem during backend build
Hi, I get this while building Compiling file GSGState.m ... GSGState.m: In function '-[GSGState(Ops) GSSetFillColorspace:]': GSGState.m:300: warning: invalid receiver type 'void *' GSGState.m: In function '-[GSGState(Ops) GSSetStrokeColorspace:]': GSGState.m:311: warning: invalid receiver type 'void *' GSGState.m: In function '-[GSGState(Ops) DPSshfill:]': GSGState.m:1121: error: 'NSNumber' undeclared (first use in this function) GSGState.m:1121: error: (Each undeclared identifier is reported only once GSGState.m:1121: error: for each function it appears in.) GSGState.m:1121: error: 'v' undeclared (first use in this function) gmake[5]: *** [obj/gsc.obj/GSGState.m.o] Error 1 Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problem during backend build
Hi, I fixed this by importing Foundation/NSValue.h I wonder why the commiter didn't notice that his changes broke the build? Riccardo Riccardo Mottola wrote: Hi, I get this while building Compiling file GSGState.m ... GSGState.m: In function '-[GSGState(Ops) GSSetFillColorspace:]': GSGState.m:300: warning: invalid receiver type 'void *' GSGState.m: In function '-[GSGState(Ops) GSSetStrokeColorspace:]': GSGState.m:311: warning: invalid receiver type 'void *' GSGState.m: In function '-[GSGState(Ops) DPSshfill:]': GSGState.m:1121: error: 'NSNumber' undeclared (first use in this function) GSGState.m:1121: error: (Each undeclared identifier is reported only once GSGState.m:1121: error: for each function it appears in.) GSGState.m:1121: error: 'v' undeclared (first use in this function) gmake[5]: *** [obj/gsc.obj/GSGState.m.o] Error 1 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem on NSColorPanel
Hi, Germán Arias wrote: Currently when you move the cursor to upwards at the color wheel, the cursor leaves a trail (see attached image. With today's SVN trunk code it works perfectly for me with the cairo backend. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
declaration after statement as GCC option
Hi, somebody suggested and added a certain flag to allow older gcc's to cope with some of the c99 features. Unfortunately that flag is not accepted by gcc 2.95 which was object of the discussion: Making all for subproject ObjectiveC2... Compiling file runtime.c ... cc1: Invalid option `-Wdeclaration-after-statement' Regards, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
-zone in NSObject
Hi, I get from some applications this kind of warning on run: in gorm: 2010-03-07 19:11:56.888 Gorm[4340] File NSObject.m: 605. In GSObjCZone GSObjCZone() is deprecated ... use -zone instead Gorm opens fine for me and appears to work, but Gregory reports it has problem, but he didn't specify what, so ìI couldn't really try to reproduce. In AddressManager instead I subsequently also get NIB errors: 2010-03-07 23:00:00.648 AddressManager[4868] File NSObject.m: 605. In GSObjCZone GSObjCZone() is deprecated ... use -zone instead 2010-03-07 23:00:01.316 AddressManager[4868] Error while establishing connection NSNibOutletConnector: 0x298cbe28 src=Controller: 0x2972a5c8 dst=NSTextField: 0x28f7ae48 label=cNameLabel: Unable to set nil value for key 2010-03-07 23:00:01.318 AddressManager[4868] Error while establishing connection NSNibOutletConnector: 0x298cbe68 src=Controller: 0x2972a5c8 dst=NSTextField: 0x28f7af08 label=cRoadLabel: Unable to set nil value for key ... and many more NSNibOutletConnector: errors AddressManager comes up, but is essentially unusable, no actions work. Where is the problem? Something inside Core or is it the app that needs some rework? Thanks, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Gorm brokeness
Hi, as with your TabView problems, I am unable to reproduce your problem. I updated GNUstep base and gui today again, I run gorm, make a new application, all palettes show up correctly and I can dragdrop everything as usual. I suspect there is something stup-dependent, since also your TabView problem cannot be reproduced by everybody. Riccardo ici...@mail.cg.tuwien.ac.at wrote: Hi, all! Because of my ongoing issues with current GNUstep from svn today I decided to do a fresh start and removed all GNUstep installation related files from my hardrive. After that I did a svn update and did a fresh build of core and gorm. Looks like Gorm is as of now rather broken. I can open an existing document of mine, I can create a new document, but the palettes do not work. I can select a palette, but I am unable to actually select an item, like a button, and drag it into a window. Also the inspector seems broken, it does not display stuff like RadioButtons or button icons. I attached two screenshots. Looks like the NSTabView issues are just syntoms of the same underlying problem. NSTabView does display correctly if it is told to display it's item bar at the bottom, screenshots are attached. Please, help TOM ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView
Hi, just for the record, I'm on Freebsd, x86-ia32, cairo 1.8.8.1 and I cannot reproduce your problem, cairo works for me. Riccardo ici...@mail.cg.tuwien.ac.at wrote: It's my own application which shows this behaviour. I do not have a theme enabled, I am using the cairo backend. Everything is built from current svn trunk. Gorm shows the same broken behaviour on my machine, screenshot is attached. I am on Ubuntu 8.04 AMD64, cairo version is 1.6.0. Thanks TOM ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: sync.m
Hi, Actually, David's original comment is a bit wide of the mark anyway ... changes to the ObjectiveC2 code are rather more than just reindentation as it needed a bug fix or two and quite a few changes to fix c99isms which prevented it building on older systems (and the whole point of a compatibility library is to allow older systems, specifically older versions of the runtime, to work without having to have masses of #ifdef's in the code). If we want to keep ObjectiveC2 and libobc2 sufficiently in sync to allow patches from one to be applied to the other, we will need to restructure quite a bit of the libobjc2 code to avoid c99 features where possible, and David put a comment to Riccardo in libobjc2 specifically asking him not to do that (since the new library will only work on more modern systems), so unless David wants to reconsider, such synchronisation is impossible anyway :-( It is not that I removed and changed stuff randomly, I just changed it where I needed it to get things to compile. So I'd like the compatibility library to continue to compile. I'm perfectly fine to use the old libobjc on the systems with old or weird compilers. As long of course as core itself doesn't require libobjc-2 feature (which I hope will be never, but that's tough to say). Things used to work well enough even on gcc 2.95 to have the whole gnustep core, gworkspace, systemprefrences, projectcenter, gorm and all of GAP compiling and working. That is all I ask, I do not expect to use Obj-c2 programs or etoile there. But breaking them gratuitously is stupid. Up to know I was able to detect and patch the stuff, it wasn't that hard, I just need sometimes help from the original author to understand what the code actually does. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
error while compiling base
WHen compiling base I now get: Compiling file GSFormat.m ... GSFormat.m:62:2: error: #error handle_llong_max defined without llong_max being defined I get this both on FreeBSD/x86 with gcc 4.2.1 as well as on OpenBSD/sparc with gcc 2.95 Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: includes/imports in gui.
Hi, Richard Frith-Macdonald wrote: Hopefully, I've now pretty much standardised on #include for C and #import for ObjC. fine. Also, be sure that import is never used for plain C. It used to work, but on recent gcc + glibc it can lead to very very strange bugs and behavious i found out in PRICE and had to fix... Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Recent changes on NSSavePanel
Hi, this is true, I have no good fix yet. It is due to changes in NSMatrix which are actually proven to be correct by checking behaviour on Cocoa. The correct way to fix is not by just having the Matrix draw its background again, but to draw it correctly both with cells and empty space. This did not happen and lead problems to theming. Fix is under investigation. --R Germán Arias wrote: After recent changes on NSSavePanel, OpenPanels and SavePanels have an ugly behavior. For example in open panel, if you back with horizontal scrollbar and then select other directory, the content of this directory is written over the content of previous directory, and this is confused. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r29500 - in /libs/gui/trunk: ChangeLog Source/NSToolbarItem.m
Fred, sure, I discovered with a freely available open-source application (namely Grr, in GAP) that toolbar items did not work correctly. The current code in Grr yields a working and resizing toolbar on cocoa, but not on gnustep, where the last item after the flexible white space gets chopped off badly. The old code of Grr worked on GNUstep and not on Cocoa... Cocoa requires the min and max sizes of a toolbar item to be set if the toolbar item gets set a view (and the search field in Grr does so). The old GNUstep code just assumed that if min and max width were the same then the item was flexible space, I think this was wrong since it doesn't allow to have resizable items apart from the space. With my fix, the proper class is checked. The toolbar at least displays correctly and is usable! Resizing is however not as smart as on the mac, since it does not take in account of min and max size at all! In the whole toolbar code those sizes are not checked. I am trying to implement the smarter resizing code, I think I have the algorithm, but probably fail to correctly get the space to allocate. If I don't get a solution to, I'll share the patch with you. Riccardo Fred Kiefer wrote: Am 07.02.2010 19:41, schrieb Riccardo Mottola: Author: rmottola Date: Sun Feb 7 19:41:04 2010 New Revision: 29500 URL: http://svn.gna.org/viewcvs/gnustep?rev=29500view=rev Log: use proper class check instead of quick and dirty size check for flexible space property Modified: libs/gui/trunk/ChangeLog libs/gui/trunk/Source/NSToolbarItem.m Could you please explain why you changed this? I had made the opposite change a while ago to allow people to define their own flexible spaced toolbar items. This was in response to bug report #26339. I never learned whether my changed helped or not. But this seems to be normal for GNUstep bug reports. For some time now I decided that when people stop complaining after a fix their problem is most likely solved. But your change should break thinks again. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUStep on Windows
Hi there, Vincent R. wrote: When will you switch to llvm on windows platform ? I can see from website that for now you are releasing a solution based on msys/mingw-4.4 and could it be possible to use a msys/llvm alternative ? Would it work ? We are not going to switch any time soon. I don't think GNUstep is going to switch anytime soon on other targets either. GCC is currently our preferred compiler. David Chisnall is doing some excellent and interesting work in getting llvm and also the libobjc2 runtime to work with GNUstep. Our goal is to support llvm+lobobjc2 as a second alternative. Supporting llvm on windows could be possible I gues, depending on how good llvm works with the msys environment. But currently I think nobody is working on that directly, David doesn't work on windows and the developers currently active on Windows have their hands full fixing other problems, like theming and backend issues. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: hi to all
Hi, great that you show interest, we hope to have you on board soon! I can help you reviewing your Italian translation. Riccardo Fred Kiefer wrote: Am 11.01.2010 09:13, schrieb inet.t...@gmail.com: can i help the project, i can translate in italian language the doc , i can find bug in programs and i know object c for porting programs? Thank you for your interest in GNUstep! Any help for GNUstep is highly appreciated. One way to start out is to work on localisation. Germain Arias just did a great translation of all our Strings and Gorm files into Spanish. Something similar for Italian would just be great. I just updated the localisation file for the Italian language to contain all new strings, you can find it in gui/Resources/Italian.lproj Before working on GNUstep you will need to sign a copyright assignment to the FSF, best get in touch with Adam Fedor (fe...@qwestoffice.net) for that. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [flame] NEWS file is useless
David Chisnall wrote: On 25 Nov 2009, at 22:39, Richard Frith-Macdonald wrote: There are actually three levels of change information ... NEWS ... just the headlines ReleaseNotes ... some more detail ChangeLog ... everything Maybe you are right and we shouldn't bother with NEWS? I'd be interested to know what others think. I'd be in favour of ditching NEWS and ChangeLog. ChangeLog has less information, in a less useful format, than the svn logs and is a hold-over from CVS not storing repository-wide change information sensibly. With svn log, you can get a log of change messages at any granularity that you like. If anyone actually cares about ChangeLog then they can do 'svn log ChangeLog' on their local machine. Stuff in the svn log can be processed easily, and is easier for people to check than the ChangeLog, for example: Well, I disagree. The utility of NEWS is questionable, but ChangeLog should be preserved. Not only in a ChangeLog I can write more than in a commit and I can group files and comment on sigle pieces of them, but it is an easy file I can check. Also, ChangeLog gets released, so it is available in the end-suer release tarball. ReleaseNotes may contain comments about incompatibilities, deprecations of methods, upgrade procedures... NEWS is perhaps more geared towards notable end-user readable things like new features, big fixes. It is perhaps more useful for an Application than the library. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [flame] NEWS file is useless
Hi, I agree with Nicola here ... it's very, very far from being a waste of space ... people do need to be able to see the changes made to the code. So your suggestion of having a script make a ChangeLog automatically from the svn logs makes a *lot* of sense. WasteOfSpace? I think that is the last of our problems. Also, one interesting point: can I correct a svn commit message? It happens that I write wrong information or that I find a better way to explain it. With the ChangeLog it is easy... I commit a new improved version. What would you do with svn? Also, A ChangeLog is easy to search. When something breaks I grep in the changelog. Old habits. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [flame] NEWS file is useless
Hi, This morning, I have inadvertently updated gnustep-base on my Debian machine, which remained at version 1.19 since april this year To my surprise, I have found at least two unannounced changes: - the property list format is now serialized directly in XML, which is somehow useful or, well, maybe not. - the NSZoneMallocAtomic function has been removed, causing SOGo users to fail in compiling SOPE yes, the plist change was to great distaste to me. I wanted to file a bug report! I was held back privately byu some of the maintainers. I saw no notice of that too, I wonder if it is perhaps something accidental? I'd rather prefer the traditional format which is easy to read and also about 1/4th more compact! About the second change I don't know, RIchard can answer you best probably. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [flame] NEWS file is useless
Hi, Hi everyone, This morning, I have inadvertently updated gnustep-base on my Debian machine, which remained at version 1.19 since april this year To my surprise, I have found at least two unannounced changes: - the property list format is now serialized directly in XML, which is somehow useful or, well, maybe not. Not sure what you mean here ... I don't think property list format should have changed ... I haven't noticed a change. I think directly ~/GNUstep/Defaults/.GNUstepDefaults ? That's XML for me now and it wasn't. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Fwd: Re: GNUstep and Linux Fund]
Hi, Thanks for the explanation. I supposed so. So the issue is rather the default behavior; I would suggest rather do nothing on right mouse click, since that is how things work in all OSes I know of. (And the app menu is visible all the time anyway...) What do you think about that? Just because others do it wrong... There is also a difference in the way the interface is done. In the OpenStep style the menu is always visible, but it can be very convenient to have it right under your mouse! Especially with large monitors or for example when working with a trackpad or other pointing devices. ALso an application can choose to supply the default menu, but use the context menu only in certain areas, where it is mostly needed. This also leads to another consideration: contextual menus are exceedingly abused. In many modern applications I notice more and more that some actions are available only as a contextual menu or as a toolbar, while every action should be available and always visible (at most, greyed out) in the main menus. This is a matter of coherent application design. Contextual menus should only be a convenient shortcut. I can imagine for example an application like a vector drawing application what allows for quick inspection of the tools, or a spreadsheet the cell. However, this is application design. Usually an OpenStep application will not need it, providing an inspector palette for example. So, I'd leave things as they are. If someone needs the behaviour he can implement it. I can imagine that for example when porting an application without really wanting to adapt the interface, one can need this feature massively. Maybe we can yet another default parameter like (hide app menu con right click), but is it really worth the complication? I love to dare to be different! Also, not everything is/was windows. For example I imagine that Amiga-users will remember clicking on the workspace for a menu... Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: New features
Hi, Specifically for the menu item colour I am thinking about making the system extension colour list, that is already used in GSToolbarView an official GNUstep mechanism, move the code over to NSColor and to add all the other colour definitions we have scattered in GNUstep gui (I think NSTableView uses some, hints to other places are welcome). That way a theme would just need to override one extra colour list. Is this a feasible approach for you? Or do you see a reason to do things differently? Having a separate color for the menu bar and for the menus themselves would help also in making a better Windows theme, since WinXP and Vista have separate colors for that. Thank you. As for GSTaskBar I already replied on the discussion list. What I would like to know about the implementation is what change will be required in NSApplication and NSWindow. We should try to come up with a generic way to handle application icons here, so that we don't need to change our gui code the next time somebody comes up with an idea for a task bar tool. I miss to understand what's really about too. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSColor extensions (Was: New features)
Hi, I am having second thoughts on my own proposal. The interplay between NSColor and GSTheme is already complex enough having to deal with just one colour list. Adding a second one will make it even harder to understand that code. My new idea now is to add the few additional colours we need to the System colour list, the one themes already override. Is this fine for everybody? That looks fine for me and that is what I originally thought. ANy arguments against that? (Richard?) Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Window manager interaction
Hi, I agree that with MS Windows style menus an application should terminate when its last window is closed and have just committed code that implements that logic. With regard to creating a new document upon program startup, I think that a document based application should always do so (regardless of the interface style) and have committed code for that too. This is very wrong. The Application controller subclasses applicationShouldOpenUntitledFile with yes or no. If it is no, clearly no new document should be opened, if yes, it should. It is up to the application to control this. Not all document based applications can handle a new document, not always it does make sense. I think of my own application PRICE, which is able to modify existing documents but which has no tools to handle a new one. I wonder how it didn't break after your patch, btw. Thus I do not understand the point of your patch: if that option gets respected, it is all what we need. I think the problem with document based applications should be handled differently. I don't think that porting an application to a different Menu Style can be done completely automatically in any case. For example even if you force opening of a New document, what happens if you close the last document? The application should definitely not close! This is Wrong! At least, not true under any condition. Do you guy actually use window? I do, sadly. Use any Office application. Use Photoshop. How do they work under windows? They have that horrible MDI - Multi Document Interface. With that interface the application can continue to exist without any documents open. It doesn't force the opening of a new document and it does NOT close after the last document is closed. Thus I think your last changes and your proposed changes are just wrong, because applications do not behave that way. Other applications like WordPad do indeed open with a new document and exit after it gets closed, but those application do handle only one document at a time! The OpenStep paradigm is inherently Multi-Document. On the other hand the behaviours you cite could be useful under certain conditions. I thus have the following thoughts: - we should find a way to implement some sort of MDI. With the GNUstep or Mac-style menu it is easy: we already to perfectly. For windows I propose the creation of a floating menu-window, thus the main menu can be tracked as a real window and doesn't disappears like now. Or we need the full-blown big window which contains everything. - the usage of MDI with in-windows menus should be controlled by a plist option: if the application does not need it it can disable it (or the other way around). Thus without intervention programs will run with in-windows menus, but a better control for porting application can be done, if the application controller is fine tuned for the different conditions. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Window manager interaction
Hi, If the application delegate responds to -applicationShouldOpenUntitledFile the result is of course always respected (and guess you've implemented it in PRICE). What I've done is just to change the default behavior for a document based application if that delegate method is not implemented. GNUstep was handling this case as NO, whereas Mac OS X considers this as YES for a document based application. All I did was to implement the OS X behavior, which I find more reasonable and which seems better suited for a Windows like environment anyway. yes, you are correct. The application's behaviour should be respected. If not, the interface style should be. I suggest that your YES default instead of NO could be extended to mac-style menus and not win95 only? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Window manager interaction
Hi, This was why I suggested doing it only if, after calling -applicationDidFinishLaunching in the delegate, there is no main window. That way, if the application is opening the last document on relaunch, or providing a 'create some specialised kind of document' window, -gui has somewhere sensible to put the menu already and doesn't need to create one. Note that I was only suggesting this behaviour for applications in the Win95 interface style. In any other interface style it's not particularly important, because the window location doesn't change when you have no main windows. Oh, and Riccardo, Microsoft deprecated MDI almost a decade ago now. Any applications still using it are violating Microsoft's HIGs. MS Office hasn't used it since Office 2000; each MS Word document is a stand-alone window. When you close the last one, Word exits. You are only partially correct. It was deprecated, but it is widely used. I use Office 2003 at work and it still essentially MDI. Try excel and try to have its document not full-sized. The whole excel is a big window then. If you program in SWING under Java, you can get the whole MDI thing again and sometimes it is the only clean way to port the application without rewriting some of its logic. If you have Multi-documents, which is what we have, there aren't many choices: closing/reopening an application is a no-go, IMHO. THus either a big encompassing window or a floating menu, which I have seen for certain programming IDEs for example. Also under BeOS this approach was used. A contorted way to get some OpenStep behaviour. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hey, I mean for for some period of time. I gives me some freedom to brake things without bothering people. One of the reason that drove me to idea of forking gui+back is when I'm developing Project Center I need to fix some things after GNUstep svn update. I need some stable basement for PC development. I tired fix things that was not broken before. To achieve what you want, ou can jsut install the latest release instead of tracking SVN trunk for svn. Since I have several computers, I arrange to have one with stable release and one with the latest stuff. Actually some of the ideas are: - remove old/unused code from 'back' (xdps, xlib); xlib is far from unused, so leave it in. xdps can indeed be removed, since the X11 extension never worked... I read that it was removed, but it is still there. But inany case Fred should look at that and do things correctly not to break anything. - move general code 'back' to 'gui' (gsc if I remember correctly); Discuss that with Fred, which is the maintainer. - finish font, image, drawing, events in GUI and ART backend (blurred lines, text positioning, focus issues with WindowMaker, start of first app in session, handling of X server events, text selection etc.). I give you 100% reason here. Things should work well and reliable on WindowMaker, so that you have a reference implementation. These are the basic things that MUST work correctly. Until then developing applications for GNUstep is a pain in back (fix things that was not broken before). I intentionally focus on UNIX, X11 and ART backend. I want at least one combination of components to work best of all (reference platform). I understand that other people has different tastes but spreading efforts never lead us to success. Understandable. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hey, I think you have many good points there. However, GNUstep is a wide project and targets many different users. Many things you want do not clash with other goals, they only divert manpower. But keep in consideration that in an opensource project people do whatever they deem interesting or useful, there isn't a central planning. 1. Maturity of GNUstep code for developers (functionality, docs, stability) 2. GUI appearance 3. Portability 4. Applications Gregory, behind all things you've mentioned I see a goal that can be expressed by the following phrase: World (all stuff outside of GNUstep) acceptance of GNUstep as alternative developer framework that will help creating of alternative desktop environment. This statement is true, though, do you agree? The problem is that it is reductive, but I think it is true. GNUstep is perhaps more. Do you really think that improving website, theme (argh!) lead us to rise of user attention to GNUstep? I don't think so. I see a lot of people comparing GNUstep with GNOME/KDE (What's I think so. We may argue about theming, but a good, informative and usable website is really useful! 3. Stop trying to work everywhere. Let's make it working good at one place, then go to another. Let's speak frankly - we can't compete with Qt. Despite the existing of DO, Objective-C and other great things. I disagree here. Being portable is a big asset and we can do that! 5. Finish gnustep-gui as it is. Problem areas are: text subsystem, fonts, graphics to name a few. Agreed... 6. Create working destop environment for developers at least. Some day I realized that I'm working inside mess of not interacting things. My plan is: - Create Login application working on that, check GAP - Create Preferences what's wrong with SystemPreferences? Recently also GWorkspace's indexing panel got fixed. - Create Workspace Manager (Workspace + WindowMaker), excellent integration of GNUstep with it (focus, app management, dock interaction). That's fine, but I'd put it lower priority. I care that we need to work well with other windowmanagers too. The best I see medium term is to enable/disable duplicate components and create a gnsutep-based configuration tool - Create Terminal application based on Alex Malmberg application. it can be improved indeed. It works well, but I miss some features. ON the todo list. - Create Mail application (GNUmail can be used as starting point). This is a sensible point. GNUmail is unmaintained sadly. Also in some sense it is too much having features here and there, while it lacks certain things i'd like. - Finish ProjectCenter (anyway it's my responsibility). Oh I hope that! I want to be able to maintain most projects in GAP with PC. You knwo I am a long-time PC user. Before even you started maintaining it... 7. Make it clean, fast and simple as NS/OS. Personally I'm tired of bloated desktop environments (KDE/GNOME). I want improved (at reasonable degree) OPENSTEP. Totally agreed! Even Mac is not clean anymore. I'd like something along mac 10.2/10.3 in terms of features, but with a more consistent, less shiny interface, more NeXTstep... It's not a plan targeting on world domination. It's plan to make comfortable development environment as I see it. And if it will be comfortable to me it can be useful to somebody else. Sure, it needs to be somethign useful and clean. I don't want to aim at GNOME or KDE; but something along the line of Xfce. Summarizing this long email: we should focus on achievable goals by narrowing down portability and loosing competition with MacOS for now. Let's agree on strong, clean, simple vision of project future and users will come. Agreed. We need both users and developers. But I can also tell you that most development in the past 2 years was good. GNUstep improved (much more than it broke). But a bit too little unfortunately in some areas and thus they are unfinished... Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hey, Gregory Casamento wrote: Accordingly, work on e.g. a GNUstep terminal app is pointless, as there are two dozen other terminal apps out there already. Strongly preferring WindowMaker is plain counter productive. I believe we need to start integrating better with other desktops/window managers. Maybe, But from my point of view we need to integrate better with Windowmaker itself! If I have focus problems, windows ordering problems, event problems, window and menu placement problems with WIndowMaker, then it is really crap!! Insisting on a own clipboard system will do nothing but confuse users. The unfortunate truth here is that there are still some features of the other guys pasteboard servers which don't server our needs at all. TO each one its ow. We can have ours :) Those dock-like miniwindows are simply annoying (for Gnome users). You can turn them off. Well, SystemPreferences has a convenient panel for defaults. If only people would install and use it... I don't know Ubuntu, but debian doesn't ship it. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hi, Ok, I went too far, Terminal works. But I doesn't answer to 'Terminal/Open shell here' service needed by GWorkspace for example. Running midnight commander inside it is... interesting. But yes, it works as a terminal for most things. Sorry :o) If you want we can work on that. Don't get me wrong : I'm not opposed to multiple applications having the same goal. I just think the GNUstep project should select a set of applications and promote them as the minimal environnement. If I want to add a settings module, should I add it to Preferences, SystemPreferences or both ? Not necessarily a big deal but it might be confusing for users. Well, GNUstep hosts one implementation: SystemPreferences. Etoile or Backbone projects can choose to have their own. Each project has its freedom to pick or replace the apps provided by gnustep. GAP chooses to use GNUstep's SystemPreferences. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hi, Well, having just glanced at a few docs, depending upon the desired level of compatibility, the approach outlined above seems reasonable. Most underline styles seem to have appeared with OSX 10.3 - i.e. the following: The real problem is not if it is dotted or continuous the problem is stopping for example the line between words or even around glyphs. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hey I believe it's one way for us to spark interest in the project is to update it's look. That's not a reason to change the default theme. It's a reason to try to develop at least one good alternative theme. You should not be proposing a change which will provoke argument when the alternative would achieve the same in a relatively non-contentious way/ If/when a genuinely better theme can be produced, people will WANT to adopt it as the default. The objective should be to develop a good theme (or multiple good themes). Indeed, I agree with this. A SystemPrefernces panel to set the theme, much like the current one in the InfoPanel, but working in the global domain... would help a lot! it would make a switch with a click and a revert with the same... and not for each application. What do you think? A small preview would be even more awesome. Maybe to simply things it could be faked with an included TIFF of a screenshot of a predefined palette Richard, could you add the ability to change the theme icon in Thematic? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hi, The first, and most obvious, is that GNUstep theming is still very young. Apart from Camaleon (does it still work?) and some of Riccardo's themes there's nothing out there. Thank you for citing the effort. It is indeed very young. I was also amazed at the little response it got, given the amount of time usually spent talking/writing about theming. My themes are just a beginning because they are pixmap themes that go 1:1 with Thematic capabilities. Code themes can bemore powerful but more complex to write, I think we should be able to do a good simple scheme by playing with pixmaps and colors only. If you look for something more subtle, look at the Neos theme. The second, which is a little deeper, is that there's no way to globally define defaults. If I'm out there creating a GNUstep package (and I mostly do for Slackware, I just need to get on it for 13.0) there's not way for me to set a default, preferred theme--which is what the GUI toolkits above allow you to do--there is just no way for me to do that. I know it's been brought up a few times in the past, and if I remember correctly it's because of the way NSUserDefaults is setup, so (again, in my opinion) that's where the problem lies. From a packager point of you that is understandable. Maybe an init script wwhich sets defaults, a bit like windowmaker does? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hi, Philippe Roussel wrote: For me, the one thing that really lowers GNUstep credibility is the super high 'bitrot factor' : a lot of the software found in the wiki is outdated, or it's website disappeared, or it won't compile or it's almost useless. Building the core librairies is good (thanks guys !) but we need a good set of working applications, easily found and easily built. True... applications need love and care just not to bit rot. Whiich gives the user a terrible impression. One example I ran recently is AddressManager and the VCFViewer inspector. There is one version in GAP, one version in Etoile. One version of VCFViewer in AddressManager tree and one in GWorkspace website and wiki page. I am working on that, you are helping me too there. The GAP version is the official Addresses, Bjoern donated it to us. GAP has become a kitchen-sink for apps not loved by their owners anymore... I try my best to keep them going and added in the last years several applications! When a core developer like Enrico leaves, it leaves a lot of stuff... I don't think everybody realized how much Enrico did for GNUstep. With the releases, the wiki pages will be corrected, etc etc. We're gettign there, just slowly. You yourself are helping me out lately! There are multiple terminal applications (gap, backbone, etoile ?) but none really usable (to my knowledge, maybe I missed something). These are harsh words? I don't know of etoile, but the one in GAP works. I use it every single day! It may miss some features but works. ANd I assume backbone's does too, the code bae is essentially the same, but the philosophies about releases, makefiles etc. differ. There is Preferences and SystemPreferences. It is lecit to have more applications that do similar things! Happens on windows too... SystemPreferences is from Enrico, it is Apple compatible. Preference's is more limited in the UI, has different modules but looks better :) GNUMail doesn't work for me and seems stalled. That is sadly very very true. TIm Kack found out what makes it crash, made a partial patch... but it is left there. He can tell us the details. But furthermore Ludovic should accept the patch, commit and make a new beta tarball. What I'm trying to say is that I think we should try to centralize things (one repository for all !) and work on a set of defined applications instead of collecting random stuff. That is not striclty necessary, but things should be clearly linked from the gnustep main site. One last thing about stable/unstable : the website frontpage advertize gnustep startup 0.23.0 as a stable release with make 2.2.0, base 1.19.1, gui 0.17.0 and back 0.17.0. In the download page, stable startup version is 0.22.0 and unstable 0.19.3. Stable base is 1.18.0 which for me means that base 1.19.1 included in startup 0.23.0 is not stable. Same thing for gui and back. Question is : what should I download ?! Our downloads are terribly confusing! I hope this doesn't sound too negative, really. I really like GNUstep and wish to use a GNUstep desktop one day :o). It is honest, which is what counts. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problem about writeInBackgroundAndNotify
Hi, Richard Frith-Macdonald wrote: 1. I start the webserver (I am admin, on linux you need to be root, since it opens port 80) 2. I retrieve a page from it 3. windows firewall notices the port access, I unlock it 4. on the standard output of the gnustep console, I see the response, but the connecting client doesn't get any data back until it timeouts. Not sure what you mean by this ... do you mean that, after a timeout, the client receives the response? Or, do you mean that a timeout occurs and the client gives up without ever receiving a response? Either way, how long is the timeout? No, the client never received the response, the client gave up and it depended on the client how long it was. I see however that you committed some changes to base and now it works fine for me on WindowsXP. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problem about writeInBackgroundAndNotify
Hi, Richard Frith-Macdonald wrote: On 22 Aug 2009, at 04:35, Guo Xu wrote: Hi Richard Thank you very much for your answer. But I have tried it again at a different machine which also have Windows7 Build 7127 platform. All my computer have platform of Windows7, I don't test on any other environment. What about your environment? Ah, I didn't realise you were using windows. I guess there could quite easily be a problem with async sockets on windows. I haven't noticed it in other programs, but I don't use windows much, in fact I don't have a windows development environment at the moment. I'll try to find time to get a windows system set up, but in the meantime perhaps someone else who uses windows might be able to help. First I tested on linux and it works. Then I did a test on Windowx XP and I get the following behaviour: 1. I start the webserver (I am admin, on linux you need to be root, since it opens port 80) 2. I retrieve a page from it 3. windows firewall notices the port access, I unlock it 4. on the standard output of the gnustep console, I see the response, but the connecting client doesn't get any data back until it timeouts. 5. the only error I see comes form an NSLog and says Unable to set blocking mode - Invalid argument [*] Riccardo [*] I find it interestng that it goes onto the stdout. Usually error messages are routed to the windows event console ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r28488 - /libs/gui/branches/testplant_1/
Fred Kiefer wrote: Gregory Casamento schrieb: Author: gcasa Date: Thu Aug 20 00:25:33 2009 New Revision: 28488 URL: http://svn.gna.org/viewcvs/gnustep?rev=28488view=rev Log: Add new branch with corrected revision number. Added: libs/gui/branches/testplant_1/ - copied from r28233, libs/gui/trunk/ Hi Greg, could you please explain the purpose of this new branch? I can see that Doug and Jonathan have started using it. Most of the changes they made up to now are perfectly legitimate for trunk (Apart from those already in trunk and that GSContext change. I am unsure about the NSOpenPanel patch) Who will be porting these changes back to trunk? Currently the commits on the branch are without Change log entries, how are we going to add these? I think I can agree with Fred here, keeping the ChangeLog would make things much easier in the futuere event of a merge. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GWorkspace, PDFkit freetype
Hi, David Chisnall wrote: If you're importing PDFKit, would it be possible to rename it? Apple has a PDFKit which has a very different set of classes to this one which, if I remember correctly, is a thin wrapper around GhostScript and doesn't provide any of the PDF metadata support that Apple's framework offers. Having a GNUstep framework with the same name but a different set of classes to an Apple one is likely to cause confusion. I never did a comparison about the two kits and I don't know which one came earlier... PDFKit is as far as I know based on xpdf and does not use ghostscript as a dependency, you are probably thinking about the GSPdf application instead. What name would you propose? I also don't know if changing the name may be a problem with the packages of the various linux and BSD distributions. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GWorkspace, PDFkit freetype
Hi, a late answer, but some work was involved. which occurs immediately after the start line above, changing directory to splash and starting to execute make in that directory, which comes immediately after the start line noted above -- even though the missing file actually exists in the path(s) provided to configure. I will see if I can resolve the problem, or if anyone else has a solution. Is there another list I should post to? I will do a follow-up post if I find out anything useful. Thanks for the input. I'll can also, as you suggest, see how I get on without PDFKit, but my impression from the Gworkspace web page was that Gworkspace *requires* it, rather than just suggesting it as an option. PDFKit is not essential for GWorkspace to build, however I understand it is handy. Since it was lastly maintained by Enrico, it is in the state of lack of maintenance as most of his other applications. I have thus decided to import PDFkit into GAP in the libs category: this allows to have a common up-to-date repository of the files and also preserves it from disappearing. I do not have however the time to work on it currently, since I am for example busy with other applications by enrico which are now in GAP. Richard Stonehouse kindly worked out some patches that make PDFkit compile again, I have tried them and it works for me. They are already in CVS. There is no official release yet because there are some bugs to be investigated. Furthermore if anybody wishes to help, a task would be to check what version of xpdf PDFKit was based on and update it as much as possible to track xpdf. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSound Reimplementation
Hey, But ... going back to the issue of avoiding changes to ivars breaking ABI in future releases ... the approach I currently favor is having a *single* ivar in the public class. This is a private id variable referring to an instance of a private class which is used to hold the real ivars. I really don't like this approach. It makes the code difficult to read, destroys locality of reference, and hurts performance. I don't like it either! I think it was discussed quite a bit and we did not agree that it was the way to go! The discussion didn't come to a conclusion (I remember we also discussed it at FOSDEM), but many agreed that this opaque single-ivar solution was bad. I personally would prefer just breaking the ABI if other solutions are a too big effort. Second place of course is David's. I cannot remember now why i didn't try it though... did your patch have some prerequisites? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSound Reimplementation
Hi, At the very least, we should just add an unused pointer for future expansion so that we can add new ivars later and not use this for ivars that are likely to remain stable for several releases. Agreed. --R ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSound Reimplementation
Hi, Sorry, I just haven't had a chance to look at installing a new/different compiler and working with that yet, though it really IS something I'd like to be playing with. However, it doesn't really have any bearing on this issue because we have to develop code for the existing compiler and will need to do so as long as we continue to support it (gcc). Yes, I remember a caveat: that was it, no gcc support. As a GNU project I'd be quite waey to drop gcc support. As for testing the patch, clang is not available as a package in gentoo, thus I was too lazy to install it in another way. This also marks the diffusion of clang up to now though. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GWorkspace, PDFkit freetype
Hi David, you are correct, PDFKit doesn't compile against freetype 2.3.9 for me either. I get very different errors though. g++ -g -O2 -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi -I. -I/usr/include/freetype2 -c SplashFTFont.cc SplashFTFont.cc:17:10: error: #include expects FILENAME or FILENAME SplashFTFont.cc: In constructor 'SplashFTFont::SplashFTFont(SplashFTFontFile*, SplashCoord*)': SplashFTFont.cc:46: error: 'FT_New_Size' was not declared in this scope SplashFTFont.cc: In member function 'virtual SplashPath* SplashFTFont::getGlyphPath(int)': SplashFTFont.cc:219: error: invalid conversion from 'int (*)(FT_Vector*, void*)' to 'int (*)(const FT_Vector*, void*)' SplashFTFont.cc:219: error: invalid conversion from 'int (*)(FT_Vector*, void*)' to 'int (*)(const FT_Vector*, void*)' SplashFTFont.cc:219: error: invalid conversion from 'int (*)(FT_Vector*, FT_Vector*, void*)' to 'int (*)(const FT_Vector*, const FT_Vector*, void*)' ... However, note that PDFkit is an optional component and not a required dependency, it is needed only to enable the contents inspector to show a preview of PDF files. So if you don't need that feature, you can do without. To view pdf's, if you have GhostScript installed, you can use the newly released GSPdf 0.3. Riccardo David Hill wrote: Hi Riccardo, I am trying to install gworkspace-0.8.7 which says it needs PDFKit and the link provided takes me to PDFKit-062609 which requires freetype, and it is freetype-2.3.9 that is the most recent version (March 12 2009). The error I keep getting when attempting PDFKit installation, despite trying variations (e.g. including different flavours of the --with-variousthings=various-existing-directories option to PDFKit configure) is: In the file included from SplashFTFont.cc:15: /usr/local/include/ft2build.h:56:38: error: freetype/config/ftheader.h: No such file or directory The file ftheader.h actually exists and is in /usr/local/include/freetype2/freetype/config/ The remainder of the freetype2 installation files/directories all appear to be intact and in the correct locations. I attempted the installation after su-ing to root. I had also previously installed freetype2 as su root successfully with the prefix /usr/local. Thanks for any pointers that might help me solve the problem. david --- On Jul 4, 2009, at 4:47 AM, Riccardo Mottola wrote: which version of GWorkspace are you trying to compile? I can configure and install the one in the SVN repository just fine. I can't find PDFkit in it though, is it in a separate repository? I have freetype 2.3.9 on my system. Riccardo David Hill wrote: ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GWorkspace, PDFkit freetype
Hi, which version of GWorkspace are you trying to compile? I can configure and install the one in the SVN repository just fine. I can't find PDFkit in it though, is it in a separate repository? I have freetype 2.3.9 on my system. Riccardo David Hill wrote: Hi everyone, The latest version of freetype was issued March 2009 (freetype2). It is not compatible with the version of PDFkit that is linked from the GWorkspace page, so PDFkit compilation fails and I can't install GWorkspace. I could install the 1999 version of freetype, but that seems silly. Does anyone know of plans that would allow GWorkspace to be installed with an updated PDF kit that uses freetype2 or do I simply install the old freetype? Thanks for your insights. david ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSCalendar and NSLocale support
Hi Dave, Dave MacLachlan wrote: Hey there... I'm looking to add NSCalendar and NSLocale to Foundation. I'm happy to implement them, but I was hoping to do it on top of ICU (http://site.icu-project.org/). Are we willing to add a dependency on ICU to gnustep? The ICU license is GNU GPL compatible... http://userguide.icu-project.org/icufaq#TOC-How-is-the-ICU-licensed- Or perhaps I should be looking somewhere else? From a glance at what dependencies debian lists for that package that it requires C++. I would really dislike to have a hard dependency on something which requires C++. http://packages.debian.org/lenny/libicu38 Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSCalendar and NSLocale support
Hi, Lars Sonchocky-Helldorf wrote: Really? SUN should use it: from http://site.icu-project.org/: cut: a long list of references Thanks, I am capable of looking up that myself. In fact, i even did before replying to the email. Besides, many of those references are more or less just there to make number. What does it mean that SuSE supports ICU? Well, I guess they package it. As Gentoo or Debian do. But do I have it installed? On one system I have it, just because I have Wine. I'm not saying it is a bad library and I am not saying it is not available. But I want to avoid me too logic. And I dislike depending on something which is C++. On the other hand, on Debian, if you have gworkspace you want libsqlite which on Debian is configured to use libicu so you end up using it. But on other systems libsqlite does not need libicu at all. A good solution could be then an internal, simplified, fall-back solution so not to have a hard dependency on it. It really depends on how much functionality is needed. Maybe the fall-back implementation ends up being very difficult or maybe it would cover 99% of what libicu does. Dave can tell us surely more. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Live Splitview patch
Hi, Submitted in revision 28291, it's doing live resize by default but users can revert back to the old mechanism by doing: defaults write NSGlobalDomain GSUseGhostResize YES Perfect. SystemPreferences in svn trunk has now the mathiching variable in the Defaults panel. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Live Splitview patch
Hi, I actually wrote the feature on a netbook... Personally I think it's the _right_ way -- the xor splitview is imho just a hack (and OSX is of course using live resizing). Now, doing live resize may expose some slowness in -gui, but instead of fighting the messenger we should fix it. That being said, it's imho fast enough as it is now. That's fine then. I would add it as a global variable to enable/it disable it. The same way live window resizing should have. Even on the mac you can disable several effects (for example with small tools). This is very useful also for remote display. Under windows, if you use RDP to access your terminal, depending on the connection, many features get disabled: shadows under the cursor, funky progressive display menus, shadows under the menus and so on. All those things have keys in the registry (which any speed-up software can tweak for you). Our version of the registry is the defaults system. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Live Splitview patch
Hmm, I prefer not to have them live... it disturbs me. Besides, 1ghz is slow for a desktop perhaps, but for some netbook it is not. --Riccardo Hi, I'm ready to commit this patch, but I wanted to give the heads up before... This basically remove the reverse splitview bar we draw to instead do live resizing. It's reasonably fast, tested on slow-ish machines (~1ghz x86 ppc), and makes things much nicer from a UI point of view. Comments before I submit ? :) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Small change in NSObject.m ASM needed for PowerPC build
David Chisnall wrote: On i386, you need -march=i586 or higher for this to work. The existing code will break at runtime, rather than link time, on an 80486 and earlier, and so I assume (from the fact no one has complained) that no one is using GNUstep on a 386/486. Well, how old is that code? Up to about a year ago I built and used GNUstep on a 486-class machine, although the CPU was not genuine intel but a compatible processor which was based on 488 ISA, it did work... Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Messaging across threads using NSThread
Nicolas, I did not use it because it is a Cocoa extension to OpenStep and I wanted to do it with the DO way. Riccardo Nicolas Roard wrote: On Mon, Apr 6, 2009 at 8:48 PM, Riccardo Mottola mul...@ngi.it wrote: Hello, in FTP (available in GAP, http://gap.nongnu.org) I do inter-thread messaging with the precise goal to have threads perform operations on the main thread GUI operations. I set up DO between the app itself this way: I was surprised that you did not mention performSelectorOnMainThread: (http://developer.apple.com/DOCUMENTATION/Cocoa/Reference/Foundation/Classes/NSObject_Class/Reference/Reference.html#//apple_ref/occ/instm/NSObject/performSelectorOnMainThread:withObject:waitUntilDone:) but it sadly doesn't seem to be implemented on gnustep (I was sure it was !?). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: ABI Compatibility (was Re: Installation woes for the average user...)
Hi, Gregory Casamento wrote: The last collective release was only two months ago. As far as the ABI is concerned that is certainly an issue. The last time we discussed it we came up with two solutions: snip I, personally, think we should implement the first option. It's the method most APIs follow and it is the method that is the most predictable. It would take some effort to do this, but it's minimal since it's really just padding the structures with a given amount of space. To the two solutions mentioned, there is David Chisnall's non-fragile ivars strategy. Now let me put down my points: - I do not want any additional runtime overhead. Performance needs to be maximum. Always. - I do not want to relay on some magic compiler and runtime trickery. I want to be easily compatible with the widest range from compilers, not only gcc 2.95, but also for example apple's compilers and who knows what else Why the two above? Portability, for example. Performance on embedded systems. (Nikolaus?) These are strengths we have and should further extend, not hamper them. So I would go for the passing solution and for clear releases. I essentially think it is not such a big problem if every change is clearly documented and minor and major releases are clear. As the library stabilizes, we break things less. The end user should just see a massive update in his package manager. This happens for gtk too... Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r27911 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m
Hi, 1. duplication of code for handling menu rearrangement. I think I wrote the original code for this for switching between vertical and horizontal menus, but that' so long ago I don't remember any detail. It sounds like Greg wrote different code to do a similar job at the point when a nib is unarchived. I guess everyone things there should be only one version. I understand it that way too. Everyone things his one is the most important... however we have two different job which share a common problem: - What to do with a NIB file from the mac? It has vertical menus. - How to draw mac-style menus having a GORM file? and, I may add, - independently if we load a NIB or a GORM, how do we display Windows-style menus? among this, we have a problem with rearrangement: We can choose to do a certain kind of conversion when loading a NIB files and greg seems to want to minimize this. On the other hand, we definitively need to do some conversion when displaying horizontal menus with mac style! And even more probably with Windows-style. So I guess the approach no conversion at all is not possible, sorry Gregory. We also see that some of this conversion is the inverse transformation: E.g.: if I load a mac-NIB and then have mac-style menus, I expect to have it look properly, even if it went through two conversions! 2. Now that menus support spacer items, there is debate about how to handle them ... I'm sure the original rearrangment code predates spacers, so it's not surprising if it doesn't do a good job with them. Yes. Personally, I changed my idea to what I discussed with Gregory a while ago: we shouldn't wipe out spacer items, instead we should support them even in GORM files. Why? If we are displaying horizontal menus with a style different than the NeXT style, we could need them. The most extreme scenario: we are writing an application to be used under Windows and we have a perfectly working Windows-theme that emulates menus very well: Separator items are needed then. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Off to FOSDEM
The same is true for me too! I hope to have connection at FOSDEM though, for email or even real-time communication with those which couldn't come. Riccardo - Original Message - From: Richard Frith-Macdonald rich...@tiptree.demon.co.uk I'll be leaving for FOSDEM tomorrow morning and won't be home again until Monday evening. My availability on email over that period will be very patchy. Hope to see a few of you there. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: plmerge crash in latest trunk
Hey,
- Original Message -
From: David Chisnall csda...@swansea.ac.uk
To: Developer GNUstep gnustep-dev@gnu.org
Sent: Wednesday, January 28, 2009 10:33 PM
Subject: plmerge crash in latest trunk
Since my last svn update I got errors complaining that an NSZone-
related symbol was missing (what is the reason for this? Breaking the
ABI is not considered friendly.). As a result I've had to recompile
everything. This wouldn't be a major problem, except that plmerge
keeps crashing.
I just compiled whole base on GNU/Hurd. back doesn't terminate compilation
because plmerge segfaults. I wouldn't wonder on Hurd... but considering you
have the problem too...
I run defaults read through the debugger, sicne it crashes too on me and
the stacktrace is very similar to yours: bucket for key and nodeforkey;;;
just different parameters.
This is a back trace from the last core it dumped:
#0 0x28449105 in objc_msg_lookup (receiver=0xa5a5a5a5, op=0x283b0aa0)
at sendmsg.c:226
#1 0x280fac8d in GSIMapBucketForKey (map=0x28ae979c, key=
{addr = 2779096485, obj = 0xa5a5a5a5, nso = 0xa5a5a5a5}) at
GSIMap.h:341
#2 0x280faef9 in GSIMapNodeForKey (map=0x28ae979c, key=
{addr = 2779096485, obj = 0xa5a5a5a5, nso = 0xa5a5a5a5}) at
GSIMap.h:579
unfortunately I have no more clues than you. I run the nsarray test in
base/testing. It fails for me after printing out method insertObject:
[NSMutableArray class] atIndex: 2]. It crashes hars in user main with
objc_msg_lookup
Riccardo
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Error while compiling a Objective C code
Hi, what are you trying to achieve and where? the gnustep windows installer comes with a fully functional environment where make of a gnustep project (both a tool or an application) will work. Thus I suppose that you are doing soemthing in a diffferent way. A nonworking or differenlty set up MinGW environment? Or an obj-c program without using gnustep-make, which does all the linking and library job for you? --Riccardo - Original Message - From: Gupta, Arjit (HP Labs India) arjit.gu...@hp.com To: gnustep-dev@gnu.org Sent: Thursday, January 22, 2009 7:25 AM Subject: Error while compiling a Objective C code Sir, I have been getting an error /mingw/lib/libmingw.amain.o:main.c:.text+0xbd:Undefined refrence to nm...@16 Collect2 :Id returned 1 exit status I am not able to compile a simple objective C class main the main. Thanks, Arjit ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: CYGWIN Problems
Hey Darryl, GNUstep on c ygwin is currently not functional anymore, although there has been discussion to revive it. The current preferrred way to have GNUstep on windows is to use mingw. We have an adapted version of MinGW which installs together will all the necessary dependencies and comes with a practical windows installer, you can download it from our site. It comes with a core and a system installer, one is the mingw base runtime with debugger, basic mingw, compiler and all requried dependencies, the rest is the core gnustep system. It comes with no applications, which you can easily install yourself as you would on a unix system. You can also update the core gnustep system easily. Using mingw, GNUstep applications run drawing the Win32 API and GDI, thus they are essentially native in the working, but not in the look, which is the same as on unix. It does not reqwuire X11 however. GNUstep on windows is currently usable, but it is not exactly on par with the standard experience on the major unix system. I have successfully compiled and sued several applications though. The development tools themselves to work, PRICE does work and most of the GAP user applications do work, not the system ones though, due to the lack of some system calls in mingw. Have a nice hacking, Riccardo - Original Message - From: Darryl Agostinelli dagostine...@gmail.com To: gnustep-dev@gnu.org Sent: Wednesday, December 24, 2008 7:08 PM Subject: CYGWIN Problems Hi, I'm having some trouble getting GNUStep to work on CygWin. Then I found out that it's not officially supported. I'm sad. So, this is a plea email. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep on DirectFB
Hi Christopher, On 2008-12-07 00:52:06 +0100 Lisbon Acid [EMAIL PROTECTED] wrote: Not sure if this has been implemented before or not, I know it has been talked about, but over the past three days I've thrown together a hacked up backend for GNUstep running through DirectFB. It is definitely not perfect or usable at this point, but with just a little bit more effort this will be solid. Just wanted to announce that on here in case anyone was interested. I consider this very interesting, it might prove important on devices where running X is an additional burden, likke embedded devices. I imagine Nikolaus might prove interestd for OpenMoko or the Zaurus, where the X11 is run as an additional appliation and not native. Here are a few screenshots. Obviously there are rendering issues. The one seen here is the color issue. There's another where it seems the image data is being rendered a pixel or two skinnier than the window, thus cacading the interface to the left one pixel on every line... soon to be fixed. The shift you are seeing is very similar to the problem the cairo backend has when exporting X11 display from a big-endian machine to a little-endian one. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSBitmap+Icns.m on Sparc
Hi,
On 2008-11-05 17:28:42 +0100 David Ayers [EMAIL PROTECTED] wrote:
typedef struct _icns_element_t {
icns_type_t elementType;
char padding[4];
icns_size_t elementSize;
} icns_element_t;
I inserted a padding of 2 and the applicationdidn't carsh anymore,
meaning that memory is accessed correctly .
Still no image gets displayed and I get an error on the console.
I checked the code and I think all the memcoty code needs to be
adapted, filling in the structure correctly. I tried to split each
memcopy in 2... first bytes and latter bytes. Is there a better way? I
wasn't completely successful, there is a point where the whole header
gets memcopied.
Riccardo
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: installation domains
be: Do not change anything significantly. Stuff are good as they are, but allow the merge of SYSTEM and LOCAL to ease FHS compliancy. For me this solves about everything except problem 1: it would make a user replace system supplied applications. I don't understand how you can solve p1 easily though. Each package should know instead of whether it is compiled for system or local. so you could add to the make, an option like PACKAGE_INSTALL=YES which could install into SYSTEM which would be used by the packager. and install say FTP.app into /usr instead of /usr/local what emerges from these thoughts, is that the OpenStep domains /System and /Local do not map to the FHS /usr and /usr/local precisely. Further, we differ from other executables that we can't have two versions. further elaborations? I wrote this in response to your bug report: by default I would expect that libobjc or SystemPreferences go into my /System. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: installation domains
Hi, On 2008-10-29 19:26:13 +0100 Richard Frith-Macdonald [EMAIL PROTECTED] wrote: Tentative policy and development proposals ... please enhance and then we can see if we can agree on the way forward. 1. We will move to FHS as the default layout for new installations I raise my hand against FHS as a default. While I am in favour of a compelte support for it at the choice of any packager with just a flag in gnustep-make, it should not be the default. I remember to everybody that the best possible would be to have /---root +---Local +---System +---Applications +---Library +---Network and so on. The next less-native version is to have root be placed anywhere. I still think /usr/GNUstep is a good choice, self contained and clean, following the example of many classics. /usr/local/GNUstep or /opt/GNUstep being two other classic options. configure --prefix=/ configure --prefix=/opt/GNUstep just at your fingertips. FHS support is good for those who strive for the standard and thus shall be supported, but it is not what we should offer by default. Sorry. my personal 2 cents. Riccaardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Colour Corruption on remote X11 with different endians
Hi, welcome to the club. On 2008-08-16 23:39:44 +0200 David Chisnall [EMAIL PROTECTED] wrote: Hi Everyone, I've done a bit more testing with GNUstep and remote X11 with the X server running on PowerPC (little endian) and the apps running on x86 (big endian): I did it the other way. With the xlib back end, everything is fine. With the art back end, almost everything is fine, but pixmaps have their colours inverted. With the cairo back end, everything has its colour inverted. xlib works fine for me too, art used to work, cairo is broken, but it is not inverted it has a strange color permutation. (everything is bluish) Since the xlib back end lacks a number of features, this isn't ideal. It is also, however, a lot more responsive than the other two (with art being slower than cairo). Ideally, they should all work. Xlib is by way faster (if you think it is smarter, it doesn';t just shovel bitmaps over the network but, for example, uses the server to display the fonts) especially if you use fonts with bitmaps and not AA. Then Menus look like local. Scrolling is slow though. just as a test I did here x86-ppc with art and the corruption is strange: some elements adre correct in color, some nots (blue cast). But for example clicking on the scrollers makes them alternatively display in the correct or in the wrong color, while test in the menus displays black and gets blue when clicking on it... I'm almost sure it used to work years ago. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
Hi, Can we officially deprecate the x11 back end in this release and recommend Cairo? The OpenBSD package, for example, uses the x11 back end and I don't think this gives people the best impression of GNUstep. I've been using Cairo since AlpenStep last year and after Fred fixed a few bugs about a month later I've had no problems with it at all. I'm, as usual, against that. x11 is a good and efficient backend. It is already deprecated and I dislike that. It works fine although it has some shortcomings, but in a typical X11 environment it can be configured very well (for example, bitmapped fonts without antialias look just gorgeous). Export display is unbeatable. Sure, it has shortcomings in image transformation and scrolling speed, but I'd rather see them solved. I personally build my RPMs with X11, one depdendency less ... Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
Hi, Can we officially deprecate the x11 back end in this release and recommend Cairo? The OpenBSD package, for example, uses the x11 back end and I don't think this gives people the best impression of GNUstep. I've been using Cairo since AlpenStep last year and after Fred fixed a few bugs about a month later I've had no problems with it at all. I'm, as usual, against that. x11 is a good and efficient backend. It is already deprecated and I dislike that. It works fine although it has some shortcomings, but in a typical X11 environment it can be configured very well (for example, bitmapped fonts without antialias look just gorgeous). Export display is unbeatable. Sure, it has shortcomings in image transformation and scrolling speed, but I'd rather see them solved. I personally build my RPMs with X11, one depdendency less ... Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
Hi, On 2008-03-02 21:00:53 +0100 Hubert Chathi [EMAIL PROTECTED] wrote: Yes, Debian currently tracks the stable branch. My understanding was that the purpose for stable was to provide a stable ABI for application developers to target. But I'm hearing more about applications that need the unstable branch to compile. (PRICE, and simpleagenda.app, at least.) So, is it better to track stable or unstable at this point? I cannot tell for sure, but PRICE had little changes since the past release, so it should compile. It misses some printing stuff which was probably added later. I guess it can be backported to stable. A newer stable release should be done indeed. Adam? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
Hi, On 2008-03-02 00:18:47 +0100 Adam Fedor [EMAIL PROTECTED] wrote: It's time for another release. I'll make an unstable release of the core libraries late next week. I also plan a stable base release, but I will not make a stable release of the gui libraries, unless there is some important patch the someone wants there (or better yet, patch the stable branch yourself so I don't have to do it). I know of no blocking issues, I should probably give a compile test on gcc 2.95 in the next days, just to be sure. About stable, since I gather Debian tracks stable (?) it would be nice to have some of the printing stuff backported to stable: PRICE doesn't compile against current debian packages. But it is just my guess: htey have an reasonably up to date base, but a horrid old gui and I thought it was that they track stable. Let me know if there is some reason I should wait. It would have been nice to have more information about bug 22373 and maybe a fix before release, but I think it can't be considered blocking. Since no one else reported it, it might be SPARC specific. Cheers, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: SystemPreferences
Hi, On 2008-01-14 16:13:18 +0100 Fred Kiefer [EMAIL PROTECTED] wrote: Why hasn't there been any new release of SystemPreferences in the last two years? This applications has improved a lot since February 2006 and it is a very important application as it most likely is one of the first applications a new GNUstep user will use. Anybody out there who wants to take up this task? This task is already in the works, tests were done and minor fixes too. A release shall be published soon and a matching RPM package too. Thanks for your patience, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Troubled begining
Hi all, I'm not sure this is the correct place to address so please forgive me if there was another more appropriate list. I installed GNUstep on a FreeBSD 6.2-RELEASE using the freebsd ports. I only have terminal access to this machine (no need for gui). The installation went fine apparently and I have my /usr/local/GNUstep tree ready to go. I then proceded to the environment configuration and tweaked my .profile and .login scripts for my shells when I noticed this weird error message. Configuration contains unknown keys - (GNUSTEP_LOCAL_LIBRARIES, GNUSTEP_USER_DIR_DOC_INFO, GNUSTEP_NETWORK_LIBRARY, GNUSTEP_USER_DIR_LIBRARIES, GNUSTEP_USER_DIR_APPS, GNUSTEP_SYSTEM_LIBRARY, GNUSTEP_NETWORK_WEB_APPS, GNUSTEP_LOCAL_LIBRARY, GNUSTEP_NETWORK_ADMIN_APPS, GNUSTEP_SYSTEM_APPS, GNUSTEP_MAKEFILES, GNUSTEP_LOCAL_TOOLS, GNUSTEP_NETWORK_DOC, GNUSTEP_USER_DIR_DOC, GNUSTEP_NETWORK_DOC_INFO, GNUSTEP_SYSTEM_ADMIN_APPS, GNUSTEP_LOCAL_USERS_DIR, GNUSTEP_USER_DIR_TOOLS, GNUSTEP_NETWORK_LIBRARIES, GNUSTEP_SYSTEM_DOC_INFO, GNUSTEP_LOCAL_ADMIN_TOOLS, GNUSTEP_LOCAL_DOC, GNUSTEP_USER_DIR_ADMIN_TOOLS, GNUSTEP_USER_DIR_DOC_MAN, GNUSTEP_NETWORK_ADMIN_TOOLS, GNUSTEP_NETWORK_APPS, GNUSTEP_SYSTEM_WEB_APPS, GNUSTEP_USER_DIR_HEADERS, GNUSTEP_LOCAL_WEB_APPS, GNUSTEP_NETWORK_DOC_MAN, GNUSTEP_LOCAL_APPS, GNUSTEP_SYSTEM_DOC_MAN, GNUSTEP_USER_DIR_WEB_APPS, GNUSTEP_LOCAL_DOC_MAN, GNUSTEP_NETWORK_USERS_DIR, GNUSTEP_SYSTEM_ADMIN_TOOLS, GNUSTEP_NETWORK_HEADERS, GNUSTEP_SYSTEM_DOC, GNUSTEP_SYSTEM_TOOLS, GNUSTEP_USER_DIR_LIBRARY, GNUSTEP_SYSTEM_HEADERS, GNUSTEP_LOCAL_DOC_INFO, GNUSTEP_LOCAL_HEADERS, GNUSTEP_SYSTEM_LIBRARIES, GNUSTEP_NETWORK_TOOLS, GNUSTEP_SYSTEM_USERS_DIR, GNUSTEP_USER_DIR_ADMIN_APPS, GNUSTEP_LOCAL_ADMIN_APPS) I've been playing around for a day but I can't seem to figure out where to look for problems. I did rebuild all a few times in different orders and with different options. I also managed to compile a very simple command line tool I was working on (only uses gnustep-base). Apparently the compilation is ok and the tool works but still... when I use it (or any other GNUstep related thing) I get this error message. Trice for instance on the login (one for gdnc, one for gpbs and one for make_services). Comparing the /usr/local/GNUstep.conf with the error I can see he's complaining of basically ALL the keys except these: GNUSTEP_USER_DIR_HEADERS=GNUstep/Library/Headers GNUSTEP_USER_DIR_LIBRARIES=GNUstep/Library/Libraries GNUSTEP_USER_DIR_LIBRARY=GNUstep/Library GNUSTEP_USER_DIR_TOOLS=GNUstep/Tools GNUSTEP_USER_DIR_WEB_APPS=GNUstep/Library/WebApplications GNUSTEP_USER_DIR=GNUstep What's wrong? Can anyone point me in the right direction please? kind regards, Riccardo De Menna ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Troubled begining
My old grandma always told me... do it yourself :-) Thx Richard and Nicola... just fetched sources and did it myself bypassing ports and it all works nice now. gnustep-make-2.0.4 gnustep-base-1.14.2 regards, rdm On 10/gen/08, at 12:23, Richard Frith-Macdonald wrote: On 10 Jan 2008, at 10:47, Riccardo De Menna wrote: Trice for instance on the login (one for gdnc, one for gpbs and one for make_services). Comparing the /usr/local/GNUstep.conf with the error I can see he's complaining of basically ALL the keys except these: GNUSTEP_USER_DIR_HEADERS=GNUstep/Library/Headers GNUSTEP_USER_DIR_LIBRARIES=GNUstep/Library/Libraries GNUSTEP_USER_DIR_LIBRARY=GNUstep/Library GNUSTEP_USER_DIR_TOOLS=GNUstep/Tools GNUSTEP_USER_DIR_WEB_APPS=GNUstep/Library/WebApplications GNUSTEP_USER_DIR=GNUstep What's wrong? Can anyone point me in the right direction please? kind regards, It looks like you have a missmatch of the package versions you are using... The base library seems to be an old version and it's complaining about configuration variables added by a later version of the make package (make 2). For make version 2 I think you need base version 1.14 or later (and also fairly up to date versions of any other packages). While I recommend using make version 2.x, you need to be aware that the change of the major version number from 1 to 2 introduced a few incompatibilities as well as a lot of improvements, so you need to get recent versions of other packages as older versions may not have been updated for make 2.x Versions of the core packages released in April 2007 or later should be fine. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: FYI and a few questions...
Hi, On 2007-07-27 14:46:06 +0200 Stefan Bidigaray [EMAIL PROTECTED] wrote: So I finally broke down and subscribed to gnustep-dev! I recently (Wednesday) started working on an implementation of Apple's ScreenSaver framework so that I can get more acquainted with GNUstep programming. I figured this framework would be fairly easy to do, which it is, for most part. I decided to split it in 3 parts, which I think is what I'd have to do anyway: the framework, a screen saver tool (which I called gssaver), and a preference module to configure it. Have a look at InnerSpace in GAP. It isn't exactly a screensaver, but it could help you. R ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Use gnustep-make for SimpleWebKit on Mac
Hi, On 2007-07-15 20:06:00 +0200 Yen-Ju Chen [EMAIL PROTECTED] wrote: Thanx. But the SWKBrowser/GNUmakefile.postamble should use 'tab' instead of 'space'. Otherwise, it will break. I think your text editor converts 'tab' into 'space' automatically. possibly, also the patch didn't apply for me and I had to retype it or do copypaste so maybe I missed something there. Fixed. I suspect it is because there are WebKit and SimpleWebKit on Mac. SimpleWebKit/WebKit.h uses WebKit/Web..., which may refer to Apple WebKit instead of SimpleWebKit. Therefore, it mess up the compiler. My suggestion is to use SimpleWebKit/Web... for all SimpleWebKit headers. I'm not sure there. Having WebKit makes compatibility easy and I have seen Nikolaus running SWK on top of cocoa appkit (which is also the way he currently tests it, since both GNUstep and myStep are incomplete or buggy), but by ising directly XCode and not GNUstep make. What changes, I don't know. -R ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Use gnustep-make for SimpleWebKit on Mac
Hi, On 2007-07-12 20:44:23 +0200 Yen-Ju Chen [EMAIL PROTECTED] wrote: I use gnustep-make on Mac and GNUstep. Here is a patch to make it work for SimpleWebKit. I know there is a xcode project for Mac. So developers can decide whether to use this patch. thanks. I had to modify it a bit, but it should still work for you. Commited. -R ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: Moving GNUstep applications to GPLv3
Hi, On 2007-06-27 02:23:27 +0200 Nicola Pero [EMAIL PROTECTED] wrote: If we decide to move to the new license, then my opinion on the best way for the project to proceed is to change the license of our applications (GWorkspace, Gorm, etc) within GNUstep itself to the GPLv3 license. All of the libraries should remain LGPL. You probably mean that the software which is currently under GPLv2 will be moved to GPLv3, and software that is currently under LGPLv2 will be moved to LGPLv3. Well, since the code we have inside GNUstep has a copyright assignment to the FSF and it has the v2 or later clause, do we have a choice at all? or any restriction with older code? Currently I don't feel strongly against it and I think there are good reasons to move forwards (so to avoid potential problems with other projects, but that may be not of too great concern for us). Although rising a great flameware about licensing, a matter in which I am only a layman, is not my intention, I do remember I followed several discussions and remember some people felt the v3 inadequate or even counterporducing and it was better to stick with v2. Linus himself felt v2 was better until shortly when forks were menaced. I didn't have a look at LGPLv3 though, since the discussions I followed originated from Kaffe. Apart from obvious arguments like to keep up with times or to comply with advices by FSF it would be nice if people could write reasons against or in favor of this license update, especially if there are points where the arguments touch GNUstep specifically. Hot points for v3 regard especially the use of code in connection with the internet, sharing and online usage, applicaiotn server providers, etc. Our WebObject clones might be interested? Cheers, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gui linking problem
Hi, I use libpng 1.2.15 from debian etch. png_sizeof is defined in /usr/include/libpng12/pngconf.h _as_a_macro_ ! Not sure, but... your problem seems to be elsewhere. Interesting. I grep-ped for that symbol in the libpng12 dir and didn't find anything. I built a newer RPM and now possibly I fixed the problem, I get another failure though, I'm not sure if it is before or after, since I switched from release to a snaphot to test also the NSAnimation stuff. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
crash of pl2link
While compiling -gui I get the following error: what is going wrong ?? I see an error but no source of it ! Compiling file GSspell.m ... Linking service GSspell ... /usr/bin/ld: warning: type and size of dynamic symbol `__objc_class_name_NSSpellServer' are not defined /usr/bin/ld: warning: type and size of dynamic symbol `__objc_class_name_NSMutableArray' are not defined /usr/bin/ld: warning: type and size of dynamic symbol `__objc_class_name_NSObject' are not defined /usr/bin/ld: warning: type and size of dynamic symbol `__objc_class_name_NXConstantString' are not defined /usr/bin/ld: warning: type and size of dynamic symbol `__objc_class_name_NSAutoreleasePool' are not defined /usr/bin/ld: warning: type and size of dynamic symbol `__objc_class_name_NSData' are not defined Creating GSspell.service/Resources... Creating GSspell.service/Resources/Info-gnustep.plist... make[2]: *** [GSspell.service/Resources/Info-gnustep.plist] Error 1 make[1]: *** [GSspell.all.service.variables] Error 2 make[1]: Leaving directory `/home/multix/gnt/gnustep-gui-0.13.0/Tools' make: *** [internal-all] Error 2 Riccardo PS: actually I think I found the problem. Just launching pl2link causes a segmentation fault. a trace is: #0 0x in ?? () #1 0x0fc416fc in _c_NSAutoreleasePool__new (self=0xfe731b4, _cmd=0xff5f1a0) at NSAutoreleasePool.m:143 #2 0x0fd01120 in NSLogv (format=0xffc4ea0, args=0x7fffea90) at NSLog.m:289 #3 0x0fd01064 in NSLog (format=0xffc4ea0) at NSLog.m:253 #4 0x0fe390bc in internal_unicode_enc () at Unicode.m:111 #5 0x0fe394b8 in GSSetupEncodingTable () at Unicode.m:319 #6 0x0fe3e004 in GSPrivateDefaultCStringEncoding () at Unicode.m:2025 #7 0x0fc061a8 in setup () at GSString.m:261 #8 0x0fc08a48 in _c_GSString__initialize (self=0xfe6b068, _cmd=0xff9fc40) at GSString.m:2693 #9 0x0f952d90 in __objc_send_initialize (class=0xfe6b068) at sendmsg.c:385 #10 0x0f952c7c in __objc_send_initialize (class=0xfe6af3c) at sendmsg.c:358 #11 0x0f952ac4 in __objc_init_install_dtable (receiver=0xfe6af3c, op=0xfe6bbe0) at sendmsg.c:327 #12 0x0f9525c4 in objc_msg_lookup (receiver=0xfe6af3c, op=0xfe6bbe0) at sendmsg.c:233 #13 0x0fc11e6c in _c_NXConstantString__initialize (self=0xfe6a100, _cmd=0xff9fc40) at GSString.m:4803 #14 0x0f952d90 in __objc_send_initialize (class=0xfe6a100) at sendmsg.c:385 #15 0x0f952a2c in __objc_init_install_dtable (receiver=0xffa03fc, op=0xff60aac) at sendmsg.c:316 #16 0x0f9525c4 in objc_msg_lookup (receiver=0xffa03fc, op=0xff60aac) at sendmsg.c:233 #17 0x0fd07368 in _i_NSNotificationCenter__addObserver_selector_name_object_ ( self=0x1003b858, _cmd=0xffad244, observer=0x10020670, selector=0xffad23c, name=0xffa03fc, object=0x0) at NSNotificationCenter.m:711 #18 0x0fe0b564 in _i_GSLazyRecursiveLock__init (self=0x10020670, _cmd=0xff67008) at GSLock.m:251 #19 0x0fd1c268 in _c_NSObject__new (self=0xffacfe4, _cmd=0xffa8e20) at NSObject.m:1268 #20 0x0fdfd91c in _c__GSLockInitializer__initialize (self=0xffa8710, _cmd=0xff9fc40) at GSCategories.m:1425 #21 0x0f952d90 in __objc_send_initialize (class=0xffa8710) at sendmsg.c:385 #22 0x0f952ac4 in __objc_init_install_dtable (receiver=0xffa8710, op=0xffa8e30) at sendmsg.c:327 #23 0x0f9525c4 in objc_msg_lookup (receiver=0xffa8710, op=0xffa8e30) at sendmsg.c:233 #24 0x0fdfded4 in newLockAt (self=0xffad0cc, _cmd=0xffc4abc, location=0xffed988) at GSCategories.m:1445 #25 0x0fdfd974 in _c_NSLock_GSCategories_newLockAt_ (self=0xffad0cc, _cmd=0xffc4abc, location=0xffed988) at GSCategories.m:1465 #26 0x0fe39230 in GSSetupEncodingTable () at Unicode.m:261 #27 0x0fe3e004 in GSPrivateDefaultCStringEncoding () at Unicode.m:2025 #28 0x0fd845cc in _c_NSString__initialize (self=0xff85a64, _cmd=0xff9fc40) at NSString.m:570 #29 0x0f952d90 in __objc_send_initialize (class=0xff85a64) at sendmsg.c:385 #30 0x0f952ac4 in __objc_init_install_dtable (receiver=0xff85a64, op=0xff66fd8) at sendmsg.c:327 #31 0x0f9525c4 in objc_msg_lookup (receiver=0xff85a64, op=0xff66fd8) at sendmsg.c:233 #32 0x0fd1bfe0 in _c_NSObject__initialize (self=0xff66ef4, _cmd=0xff9fc40) at NSObject.m:1133 #33 0x0f952d90 in __objc_send_initialize (class=0xff66ef4) at sendmsg.c:385 #34 0x0f952c7c in __objc_send_initialize (class=0xfe731b4) at sendmsg.c:358 #35 0x0f952ac4 in __objc_init_install_dtable (receiver=0xfe731b4, op=0x1001173c) at sendmsg.c:327 #36 0x0f9525c4 in objc_msg_lookup (receiver=0xfe731b4, op=0x1001173c) at sendmsg.c:233 #37 0x1a70 in main (argc=1, argv=0x7664, env=0x766c) at pl2link.m:49 #38 0x0f5d15fc in __libc_start_main () from /lib/libc.so.6 any ideas? This is my older box where the glibc doesn't have the widechar support. May it be because of this, Richard? Cheers, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
gui linking problem
Hi, after the fixes of NSAnimation and some other small stuff I fixed myself, gui compilation on my older box fails with: Compiling file set_show_service.m ... Linking tool set_show_service ... /usr/bin/ld: warning: type and size of dynamic symbol `__objc_class_name_NSProcessInfo' are not defined /usr/bin/ld: warning: type and size of dynamic symbol `__objc_class_name_NXConstantString' are not defined /usr/bin/ld: warning: type and size of dynamic symbol `__objc_class_name_NSAutoreleasePool' are not defined ../Source/./obj/libgnustep-gui.so: undefined reference to `png_sizeof' collect2: ld returned 1 exit status make[2]: *** [obj/set_show_service] Error 1 make[1]: *** [set_show_service.all.tool.variables] Error 2 make[1]: Leaving directory `/home/multix/gnt/gnustep-gui-0.13.0/Tools' make: *** [internal-all] Error 2 [EMAIL PROTECTED] gnustep-gui-0. is png_sizeof something that hsould be provided by my png library? I still have installed: libpng-devel-1.2.5-1 libpng-1.2.5-1 which used to be enough up to the past release I compiled... I thought that versions differing by minor release numbers were all OK. is an update mandatory or is something else wrong? -Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
