GNUstep Testfarm Results
Test results for GNUstep as of Sun Jan 28 06:34:18 EST 2007 If a particular system failed compilation, the logs for that system will be placed at ftp://ftp.gnustep.org/pub/testfarm If you would like to be a part of this automated testfarm, see http://wiki.gnustep.org/index.php/Developer_FAQ#How_can_I_take_part_with_a_GNUstep_autobuilder_for_the_testfarm.3F Fail Compile i386-unknown-freebsd6.2 Sun Jan 28 18:16:22 CST 2007 Success Compile i386-unknown-netbsdelf3.1 Sun Jan 28 03:56:38 CET 2007 Success Compile powerpc-apple-darwin8.8.0 Sun Jan 28 00:29:55 MST 2007 Success Compile sparc-sun-solaris2.7 Sun Jan 28 01:32:51 EST 2007 Success Compile x86_64-unknown-linux-gnu Sun Jan 28 04:09:15 GMT 2007 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Delay of release....
Sorry about the delay I've been extremely busy for the past couple of weeks. I will move the release today. -- Gregory Casamento - Original Message From: Richard Frith-Macdonald [EMAIL PROTECTED] To: Adam Fedor [EMAIL PROTECTED] Cc: GNUstep developer list gnustep-dev@gnu.org Sent: Saturday, January 27, 2007 3:03:59 PM Subject: Re: Delay of release On 27 Jan 2007, at 19:59, Adam Fedor wrote: On Jan 26, 2007, at 10:13 AM, Guenther Noack wrote: Speaking of GNUstep bugfix releases, what happened to the release of version 1.13.1, that fixes the buffer overflow issue I reported ( https://savannah.gnu.org/bugs/?18366)? I've seen that the stable branch is tagged 1.13.1 now, but there's still no release made public, neither on the web page nor on the ftp. I know that your time is limited and this is all done on a volunteer basis, but this is certainly not a good sign for a framwork which wants to be used in professional applications. The package is still in the incoming directory on the ftp server. I could move it and update everything, I just was unsure if Richard or Greg wanted to wait for something. Let me know. I put it up there for Greg to put in place (I don't have write access to do it myself) and emaild him about it a few weeks ago. Don't know whether he just hasn't had time or there is some other reason. ___ 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
Recent NSMenu changes..
I don't really like the new NSMenuItemCell behaviour which adds #, /, +, ^ to show the key mask before the key equivalent.. i think its unattractive and makes it hard to quickly see the key equivalent, and doesn't increase the comprehension of which keys to press since they don't map to the actual keys to be pressed on the keyboard ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Recent NSMenu changes..
Matt Rice schrieb: I don't really like the new NSMenuItemCell behaviour which adds #, /, +, ^ to show the key mask before the key equivalent.. i think its unattractive and makes it hard to quickly see the key equivalent, and doesn't increase the comprehension of which keys to press since they don't map to the actual keys to be pressed on the keyboard It is a good point that this does look ugly and that it does not really help a user to judge what modifier she needs to press to get the key equivalent working. I did copy this code from mySTEP because up to then the GNUstep code had only displayed the key equivalent itself. This might in some cases even be a non printable character like return or escape, so some change was needed. But our old code also did not show the key modifier. I think in May last year Richard corrected the GUI code to respect the key equivalent modifier, since then other modifier apart from ALT where possible, but the GUI did not give a glue about which modifier where needed. So seeing an s as the key modifier you had to go through all the possible modifier combinations to trigger the short cut. This clearly needed to be changed. The question now is, if you have a better proposal on how to display the modifier? Any idea here would be welcome. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Recent NSMenu changes..
On 2007-01-28 12:53:23 -0800 Fred Kiefer [EMAIL PROTECTED] wrote: Matt Rice schrieb: I don't really like the new NSMenuItemCell behaviour which adds #, /, +, ^ to show the key mask before the key equivalent.. i think its unattractive and makes it hard to quickly see the key equivalent, and doesn't increase the comprehension of which keys to press since they don't map to the actual keys to be pressed on the keyboard It is a good point that this does look ugly and that it does not really help a user to judge what modifier she needs to press to get the key equivalent working. I did copy this code from mySTEP because up to then the GNUstep code had only displayed the key equivalent itself. This might in some cases even be a non printable character like return or escape, so some change was needed. But our old code also did not show the key modifier. I think in May last year Richard corrected the GUI code to respect the key equivalent modifier, since then other modifier apart from ALT where possible, but the GUI did not give a glue about which modifier where needed. So seeing an s as the key modifier you had to go through all the possible modifier combinations to trigger the short cut. This clearly needed to be changed. The question now is, if you have a better proposal on how to display the modifier? Any idea here would be welcome. Not really, the only thing i could think of was something like using tooltips to give a textual representation of the key equivalent e.g. Quit: Terminates the application. Key equivalent: command-q Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Recent NSMenu changes..
All, Perhaps we could put a set of images to represent the key masks needed.The #/+/- scheme adds absolutely nothing and only clutters the interface. It would be better to implement a mechanism which shows some images (pehaps *original* versions of the same symbols used in Cocoa) to represent Control, Command, Shift, and Alt. GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: gnustep-dev@gnu.org Sent: Sunday, January 28, 2007 3:53:23 PM Subject: Re: Recent NSMenu changes.. Matt Rice schrieb: I don't really like the new NSMenuItemCell behaviour which adds #, /, +, ^ to show the key mask before the key equivalent.. i think its unattractive and makes it hard to quickly see the key equivalent, and doesn't increase the comprehension of which keys to press since they don't map to the actual keys to be pressed on the keyboard It is a good point that this does look ugly and that it does not really help a user to judge what modifier she needs to press to get the key equivalent working. I did copy this code from mySTEP because up to then the GNUstep code had only displayed the key equivalent itself. This might in some cases even be a non printable character like return or escape, so some change was needed. But our old code also did not show the key modifier. I think in May last year Richard corrected the GUI code to respect the key equivalent modifier, since then other modifier apart from ALT where possible, but the GUI did not give a glue about which modifier where needed. So seeing an s as the key modifier you had to go through all the possible modifier combinations to trigger the short cut. This clearly needed to be changed. The question now is, if you have a better proposal on how to display the modifier? Any idea here would be welcome. Cheers, Fred ___ 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
FHS compliance for libraries (was Re: gnustep-make experiment)
All, Sorry to chime in so late on this one, RL has kept me quite busy over the last few weeks. :) Wouldn't it be possible to change make so that it handles both setups (i.e. FHS or GNUstep)?This way we could have one set of GNUmakefiles to handle everything, instead of two (as Nicola suggested). I believe that all of the extra setup that is necessary to use the libraries outside of the FHS represents a barrier to entry to some users as they may not feel comfortable about using a set of libraries which requires them to make basic system level change to ld.conf. It would be nice if there was an option to install the libraries in an FHS compliant manner to allow them to be used by GNUstep applications or, possibly, by other non-GNUstep programs. Before anyone suggests it, I believe the value of splitting APPLICATION bundles into the FHS (the various resource dirs) is dubious at best and this debate will be left for another time. For now we need to focus on making Libraries FHS compliant. Thanks, GJC -- Gregory Casamento - Original Message From: Nicola Pero [EMAIL PROTECTED] To: David Ayers [EMAIL PROTECTED] Cc: Richard Frith-Macdonald [EMAIL PROTECTED]; gnustep-dev@gnu.org Sent: Thursday, January 25, 2007 8:58:02 PM Subject: Re: gnustep-make experiment Personally I'd prefer to suspend the release until we have an environment that has a chance of remaining stable. It seems that we already require -make users to adapt thier projects for this release (I remeber you cleaning up many projects in SVN) and it seems they may need to adapt again for the subsequent release. That's a good point to discuss, on the other hand sooner or later we need to ship the changes so they start getting widespread. I believe we have enough changes to ship a new release! The main changes in the new gnustep-make are: * libraries have now the same name no matter if you compile them with debug, porofile, static or what. _d, _p, _dp etc. are gone. * applications have now the same name no matter if you compile them with debug or what. Gorm.debug is gone. Now it's only Gorm.app. * all object files are now put in ./obj. shared_obj, shared_debug_obj, etc. are gone. Those may require projects that contain custom makefile code to be updated! The other main change is that using GNUSTEP_SYSTEM_ROOT, GNUSTEP_LOCAL_ROOT, etc. in makefiles is now discouraged (because it won't work with Linux FHS). This has no effect though, for now you can happily use them. Also, the new release will work without sourcing GNUstep.sh, in which case you can't really use the GNUSTEP_SYSTEM_ROOT, etc. shell variables any more. They are effectively obsolete. Finally, the new gnustep-make supports GNUSTEP_INSTALLATION_DOMAIN and it's strongly recommended that this is used instead of GNUSTEP_INSTALLATION_DIR (GNUSTEP_INSTALLATION_DIR won't work with Linux FHS). You don't need to change it now, but over time we hope everyone will switch to GNUSTEP_INSTALLATION_DOMAIN I suppose maybe you (and Helge) are right, we could wait a few more months and finish off all changes, then we ship a gnustep-make 2.0.0 so there is a single major upgrade. ;-) It actually makes quite some sense, I'm tempted to do that now. :-) Comments welcome Thanks ___ 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
