[Gnustep-cvs] gnustep REPOSTORY_HAS_MOVED
CVSROOT:/sources/gnustep Module name:gnustep Changes by: Gregory John Casamento gcasa 10/12/16 02:53:55 Added files: . : REPOSTORY_HAS_MOVED Log message: Make it clear that the repo is no longer here, but at gna. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/gnustep/REPOSTORY_HAS_MOVED?cvsroot=gnusteprev=1.1
Re: xcodeproject2dot.py
Yes, go ahead and commit it. Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Hans Baier hansfba...@googlemail.com To: GNUstep Developer gnustep-dev@gnu.org Sent: Sat, February 13, 2010 12:57:59 AM Subject: xcodeproject2dot.py Hi, in preparation to work on pbxbuild I wrote a python utility which visualizes the structure of an xcode project file. It currently runs on OS X (Yes, I got a new mac mini :). Linux users may need to install plistlib for python, if that is available. Here is an example: http://dl.dropbox.com/u/3377727/GNUstep/iphoneapp.svgz And here is the tool: http://dl.dropbox.com/u/3377727/GNUstep/xcodeproj2dot.py It is not considered finished yet, but already quite useful for understanding what's going on inside a project file. gcasa: Should I commit it to pbxbuild/tools? Kind Regards, Hans ___ 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: Recent changes on NSSavePanel
This should be fixed now. Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Germán Arias ger...@xelalug.org To: Dev-GNUstep gnustep-dev@gnu.org Sent: Fri, February 12, 2010 11:57:12 AM Subject: Recent changes on NSSavePanel 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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Skype conference during FOSDEM for people in US....
Hey guys... it would be nice if we could arrange a skype conference (or we could use iChat, if you like) to allow people in the US to have contact with you guys over there. Let me know when is a good time to set something like this up as I would really like to see some of you in, at least, the virtual flesh. :) Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Recent changes on NSWindow.m
I'll take a look and see why they'rebreaking things... Thanks. Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Germán Arias ger...@xelalug.org To: Dev-GNUstep gnustep-dev@gnu.org Cc: Gregory John Casamento greg_casame...@yahoo.com Sent: Sun, January 17, 2010 12:33:02 AM Subject: Recent changes on NSWindow.m With the recent changes on NSWindow.m all GNUstep apps are unusable. For example on Ink you can't write, on Gorm you can't add components from the palette, and in any app you can't write inside NSTextField objects. I'm not sure if this is a bug, or if you have planed more changes to complement these. ___ 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
Fw: Invitation to GNUStep for SCALE 8x
Guys!! If anyone would like to give a talk about GNUstep at SCALE, please let Gareth know. Thanks, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Forwarded Message From: Gareth J. Greenaway gar...@socallinuxexpo.org To: greg_casame...@yahoo.com Cc: Joe Smith j...@socallinuxexpo.org Sent: Wed, October 28, 2009 10:43:24 PM Subject: Invitation to GNUStep for SCALE 8x Greetings Gregory, I hope this email finds you doing well. We have begun the planning for the 8th annual Southern California Linux Expo and I wanted to formerly invite GNUstep to participate again at our show. The show will be taking place February 19th - 21nd, 2010 once again at the Westin LAX in Los Angeles, CA. I am also including a link to our Call for Papers if anyone from GNUstep is interested in submitting a talk for consideration. http://www.socallinuxexpo.org/scale8x/scale-8x-call-papers Thanks! -- Gareth J. Greenaway g...@socallinuxexpo.org Voice - 877-831-2569 x130 Southern California Linux Expo http://www.socallinuxexpo.org ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes to NSScrollView decoding
I'll test it. Thanks. Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Fred Kiefer fredkie...@gmx.de To: GNUstep Developer gnustep-dev@gnu.org Sent: Monday, September 7, 2009 12:25:39 PM Subject: Changes to NSScrollView decoding I just added a patch from Quentin for the decoding of NSScrollView. The details for this can be found in the bug report #27311. I added some more changes to this patch and would recommend that especially Gregory should check whether his code still works. The is a (now commented out) piece of code in this methods that is really strange and should never have been needed (with [self tile] correctly placed). But then Greg never gave the example code that justified this code and I might have broken something here. 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
Re: New gui/back release?
Fred, I can undo the change. The last email you sent wasn't clear with respect to whether you wished me to remove it or to fully implement it. I chose to fully implement it. I can remove it and stub out the implementation, if we want to do an ABI compatible release this time around. Thanks, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Fred Kiefer fredkie...@gmx.de To: Developer GNUstep gnustep-dev@gnu.org Cc: Adam Fedor fe...@qwestoffice.net Sent: Monday, July 27, 2009 9:26:08 AM Subject: Re: New gui/back release? Fred Kiefer schrieb: why do you expect the next release to break ABI compatibility? What I wanted to do is a bug fix release and this is why I restricted myself to non ABI breaking changes. Looking back through the ChangeLog file I noticed that Greg has added an attached sheet ivar to NSWindow, this will break ABI even though there still is no functionality behind that ivar. The idea of doing a release before your change landed was to give your code some time to mature while it is exposed to multiple users with different setup. Two months will be the minimum for that, we should rather give it a bit more time, given the slow speed at which people pick up GNUstep SVN changes. This would result in no GNUstep release for that time and I really would have loved to see the bug fixes out there. For example the cairo scrolling fix is something that the Etoile people have been waiting for a long time. In the meantime Greg has commit some more of his attached sheet changes, code which I find of limited quality. There also hasn't been any sign of him fixing the NIB loading issues for NSTextView he introduced two months ago. I started to work on a fix here myself, but really I at the moment I am not able to stop the gui code from degrading. OK, I stop complaining and come up with a way forward. I will give Greg time until this weekend to fix his sheet change, otherwise I will clean up myself and after about a week of test we should be able to make a gui and back release. Somebody else will have to speak up whether base is ready for a release. Greg did some clean up here, that should make us ready for a release. As Greg didn't undo his ivar change, I expect that he wants a full release with changed soname, not just a bug fix release. This is rather unfortunate as the next release after this will also be an ABI breaking one. 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
Corbra language... gnustep backend...
All, An old friend of mine brought this to my attention... http://cobra-language.com/forums/viewtopic.php?f=4t=374 Please take a look. Later, Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Updated Roadmap
Very good point. :) Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Nicola Pero nicola.p...@meta-innovation.com To: Gregory Casamento greg.casame...@gmail.com Cc: GNUstep Developer gnustep-dev@gnu.org Sent: Thursday, March 26, 2009 6:03:39 AM Subject: Re: Updated Roadmap On 25 Mar 2009, at 20:37, Gregory Casamento wrote: I've updated the 1.0 Roadmap here: http://wiki.gnustep.org/index.php/Roadmap I'm throwing this out for discussion to find out where everyone thinks we stand on some of these goals and what should be added/changed on this. I support you in your efforts to organize our roadmap ... but I would rather have roadmaps for the separate packages rather than a global GNUstep 1.0 roadmap. ;-) Mostly because the simple idea of a yet-to-come GNUstep 1.0 downplays the fact that the non-graphical part of GNUstep (which is at least half of core, ie gnustep-make and gnustep-base) reached 1.0 many years ago! And they are absolutely production-ready code. :-) 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
Re: [Gnustep-cvs] r27874 - in /libs/gui/trunk: ChangeLog Source/NSCell.m
If Apple really allows non-String parameters to setStringValue: this is
rather a bug then a feature. If you insist to add this to GNUstep, it is
fine for me, but at least we should not break working GNUstep code for this.
Since it is documented on their site I would not classify this as a bug. It is
a bug on our side if we don't have it, in my opinion.
GC
Gregory Casamento -- Principal Consultant - OLC, Inc
# GNUstep Chief Maintainer
From: Gregory John Casamento greg_casame...@yahoo.com
To: Fred Kiefer fredkie...@gmx.de; GNUstep Developer gnustep-dev@gnu.org
Sent: Monday, February 16, 2009 11:39:35 AM
Subject: Re: [Gnustep-cvs] r27874 - in /libs/gui/trunk: ChangeLog
Source/NSCell.m
I will provide example code which will illustrate that the change is correct.
Please also look at the documentation on apple's site which explains what
happens when a non-NSString is passed.
Gregory Casamento -- Principal Consultant - OLC, Inc
# GNUstep Chief Maintainer
From: Fred Kiefer fredkie...@gmx.de
To: Gregory Casamento greg_casame...@yahoo.com; GNUstep Developer
gnustep-dev@gnu.org
Sent: Monday, February 16, 2009 11:27:20 AM
Subject: Re: [Gnustep-cvs] r27874 - in /libs/gui/trunk: ChangeLog
Source/NSCell.m
Gregory Casamento wrote:
Author: gcasa
Date: Mon Feb 16 01:31:23 2009
New Revision: 27874
URL: http://svn.gna.org/viewcvs/gnustep?rev=27874view=rev
Log:
* Source/NSCell.m: Change to implement 10.3 and later behavior for
the method setStringValue: as documented in Apple's documentation
for the method. This behavior was observed on Cocoa under
Mac OS 10.5.
Modified:
libs/gui/trunk/ChangeLog
libs/gui/trunk/Source/NSCell.m
I don't like this change and I would like to explain why. The first half
of your change, the bit in setObjectValue: is without any external
relevance:
///
// If the thing that was assigned is not a string, but
// responds to stringValue then get that.
///
if([_object_value respondsToSelector: @selector(attributedStringValue)])
{
newContents = [_object_value attributedStringValue];
}
else if([_object_value respondsToSelector: @selector(stringValue)])
{
newContents = [_object_value stringValue];
}
newContents = [_object_value description];
Here you first get a value and then override it with the old default. We
really need to clean this up, as the basic idea is ok.
As for the second half of the change it may assign an attributed string
to the _contents ivar without setting
_cell.contents_is_attributed_string to YES. This could break things
horribly. I would suggest that when the formatter is nil we just call
setObjectValue: without looking at that value and try to resolve things
there.
If Apple really allows non-String parameters to setStringValue: this is
rather a bug then a feature. If you insist to add this to GNUstep, it is
fine for me, but at least we should not break working GNUstep code for this.
I make these changes and you can comment on them. OK?
Fred
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r27827 - in /libs/gui/trunk: ChangeLog Source/NSToolbar.m
I tested the change in a number of different applications and was unable to cause this to occur. I believe this might have been prevent something which was happening under the old architecture of the toolbar. Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Fred Kiefer fredkie...@gmx.de To: Gregory Casamento greg_casame...@yahoo.com Cc: GNUstep Developer gnustep-dev@gnu.org Sent: Tuesday, February 10, 2009 3:56:00 AM Subject: Re: [Gnustep-cvs] r27827 - in /libs/gui/trunk: ChangeLog Source/NSToolbar.m Gregory Casamento wrote: Author: gcasa Date: Tue Feb 10 02:21:07 2009 New Revision: 27827 URL: http://svn.gna.org/viewcvs/gnustep?rev=27827view=rev Log: * Source/NSToolbar.m: (-windowDidUpdate:): Automatically update the toolbar on every window update. This makes sure that no matter what window an event happens in the toolbar gets properly updated for ALL windows. Modified: libs/gui/trunk/ChangeLog libs/gui/trunk/Source/NSToolbar.m The code you removed claims to avoid a call cycle. Did you make sure that this protection is no longer needed? if (!_inside || _validating || [[NSApp currentEvent] type] == NSMouseMoved) return; // _validating permits in the case the UI/window is refreshed by a validation to // avoid have windowDidUpdate called, which would cause a loop like that : // validate - view update - windowDidUpdate - validate etc. I might well be that it was never needed at all, we just need to make sure things don't get worse through our improvements. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Off to FOSDEM
Have a safe trip. Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Richard Frith-Macdonald rich...@tiptree.demon.co.uk To: Developer GNUstep gnustep-dev@gnu.org Sent: Wednesday, February 4, 2009 12:23:30 PM Subject: Off to FOSDEM 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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
David, Simply because an exception is thrown and not caught does not necessarily mean that the application is in an unknown state. Indeed some applications may have come to rely on this behavior and it makes it very difficult to port applications which do this without refactoring. As far as being dangerously wrong I believe it's equally wrong (or, perhaps, worse) to have the application blow up when an exception is easily recoverable and isn't fatal. The philosophy is that, if it is possible to continue... it should continue. It is up to the app developer to catch the exception and take appropriate action. If it's a fatal exception, it should be up to the developer of the application to cause the app to terminate. We should NOT force the decision. Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: David Ayers ay...@fsfe.org To: Gregory Casamento greg.casame...@gmail.com Cc: Adam Fedor fe...@qwestoffice.net; Developer GNUstep gnustep-dev@gnu.org Sent: Thursday, February 5, 2009 12:50:15 AM Subject: Re: Allowing Applications to continue after exception... Am Mittwoch, den 04.02.2009, 23:52 -0500 schrieb Gregory Casamento: The attached test program does not crash on Mac OS X when the button is pressed, but does crash on GNUstep. The button calls the action: method in Controller which immediately throws an exception. I believe this confirms that GNUstep's behavior is inconsistent with Cocoa. I can test on OpenStep, but I suspect that the behavior is the same there as it is on Cocoa. FWIW, IIRC this inconsistency was intentional an I believe for a very good reason. I thought we had documented it at the time but I can't dig it up easily right now. An uncaught exception indicates that the application is in an undefined state. For certain type of applications (like viewers) this can be ignored. For editor application this could mean that the document being edited could be corrupted and saving it cause data corruption. This thread is the only reference I found in which we suggested some type of Developer-Mode which indicates that I know what I'm doing, let me debug, will you?!. http://lists.gnu.org/archive/html/discuss-gnustep/2004-10/msg00092.html I still believe that handling generic handling of exceptions in the runloop is a dangerously wrong and an implementation detail that we shouldn't try to be compatible with. But others may disagree. Cheers, David ___ 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-cvs] r27706 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m
Fred, The NSDrawer change: * I think that setFrame:display:animate: didn't exist when I originally wrote the code for NSDrawer. The issue is that on Windows systems and on some slower systems the code that was there (in NSDrawer) was very slow and was causing the drawer to open very very slowly. The GSNibLoading change: * As stated in the ChangeLog, this one is temporary until I find all of the places this is crashing. The issue is not in GSNibLoading itself, but is in some of the nib loading code (initWithCoder: methods) of objects being loaded. I believe this to be the case since I have found a few places where objects were not being retained properly (GSMenuItemSeparator, as one example) that were causing crashes. I put this temporary change in place to prevent crashes for people who simply want their apps to work (yes, at the cost of a memory leak) until I can locate all of the places where this is an issue. Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Fred Kiefer fredkie...@gmx.de To: Gregory Casamento greg_casame...@yahoo.com; GNUstep Developer gnustep-dev@gnu.org Sent: Wednesday, January 28, 2009 2:43:20 AM Subject: Re: [Gnustep-cvs] r27706 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m Gregory Casamento wrote: Author: gcasa Date: Tue Jan 27 21:33:17 2009 New Revision: 27706 URL: http://svn.gna.org/viewcvs/gnustep?rev=27706view=rev Log: This is a temporary change. Commenting out RELEASE(_connections) will be reverted ASAP. Modified: libs/gui/trunk/ChangeLog libs/gui/trunk/Source/GSNibLoading.m libs/gui/trunk/Source/NSDrawer.m Could you please explain these two changes? I am more interested in the one for NIB loading, although the drawer change also surprised me. The old code there looks strange, why didn't we use setFrame:display:animate: in the first place. Still it looked like a working feature... The other change is more interesting. Did you switch of the memory management for NIB connections because of the ugly memory problems this is causing on applications like Bean? We have noticed this during our session in Bergamo as well. My impression there was that outlets set via the NIB connection mechanism get deallocated behind the back of the application. We didn't have the time to investigate this in detail. My first idea was the perhaps the mechanism we use to set the outlets doesn't follow the documented memory management rules, but as far as I can tell this wasn't the case. I think we are using GSObjCFindVariable() and GSObjCSetVariable() and these should work correctly. Perhaps we could switch to setValue:forKey: here to have a more general mechanism in place. But basically this would end up calling the same code, it is just a bit cleaner and easier to understand. Anybody out there with an idea, what might go wrong here? Or perhaps I am looking at the wrong bit of code. It might well be that the memory leak happens somewhere completely different. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Commit r27569
Wolfgang, Apple's implementation apparently doesn't change the menu items' states when -setAutoEnable: is called (with whatever argument), so I think we shouldn't bother either. Thanks for your input and verifying the behavior on Mac OS X. Given what you've said, my change is definitely wrong. I'll review the change I made and see if there's a better way to approach the problem. The issue I was having is that I am trying to get the menus in an NSPopUpButton instance to be enabled when loading from a nib. It might be better to set autoenable to NO and explicitly enable them in initWithCoder: instead of doing this. Thanks, :) Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Wolfgang Lux wolfgang@gmail.com To: Gregory John Casamento greg_casame...@yahoo.com Cc: GNUstep Developer gnustep-dev@gnu.org Sent: Saturday, January 17, 2009 7:21:32 PM Subject: Commit r27569 Gregory, * Source/NSMenu.m: Correction to previous change. Update when setAutoenableItems: value is changed. Altered update to enable menu items when autoenable is not being performed. I'm not sure what you are trying to achieve here, but this change is definitely wrong. If auto enable for a menu is disabled, the menu items' states are not NSMenu's business. At best one might consider enabling all items at the time auto enable is disabled, but then the -update method is certainly the wrong place for doing this. Note that update is called from the -itemChanged: method, which in turn is called whenever a menu item is changed, e.g., when the application attempts to disable it! Anyway, Apple's implementation apparently doesn't change the menu items' states when -setAutoEnable: is called (with whatever argument), so I think we shouldn't bother either. Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: our Devroom - what do we want to do there - call for papers
David, Just throwing these thoughts out there... In order to raise interest we need to reach out to more people who have Cocoa software on Mac OS X and help them realize that GNUstep is a viable environment for porting their software. We have a number of examples of modern Mac OS X Cocoa applications which have been ported: Bean, Flexisheet, GNUspeech so there is no doubt that GNUstep is maturing. One thing I will say, from experience, is that we do need further improvement to pbxbuild (which I have been working on). It now does an almost perfect job of translating .xcodeproj to PC projects at this point, but there are still a few gotchas. The ability for Mac OS X developers to come over and be able to build their apps with no changes or, at least, very minimal ones is something that is very close, but not entirely working. It does work in most cases for simple projects, but for complex ones it's a problem. We also have to start appealing to more people in the GNU/Linux world who are interested in Objective-C and a Mac-like experience, but don't necessarily want a Mac. There seem to be plenty of them around. :) I want GNUstep to be seen as a full development environment as well as conduit for people to bring their Cocoa applications to a wider audience. In my experience reaching out to companies, individuals and other open source projects who might be willing to help us are several good ways to bring attention to GNUstep. :) Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: David Chisnall thera...@sucs.org To: Adam Fedor fe...@qwestoffice.net Cc: Developer GNUstep gnustep-dev@gnu.org Sent: Tuesday, January 13, 2009 6:36:09 AM Subject: Re: our Devroom - what do we want to do there - call for papers On 13 Jan 2009, at 03:14, Adam Fedor wrote: We had three. One dropped out before the start even, I think due to family problems. This one looked very promising at the start, but unfortunately someone else thought so too and he was offered an internship that looked more appealing than spending the summer working on GNUstep. One basically did not submit code that was anywhere near done. Basically just a skeleton. This was mine. Two things to take away from this: 1) Due to the way the SoC is set up, we should favour students in the USA. I don't really like this, but the dates are fixed according to US term dates - there is no flexibility and most other countries have quite different summer holiday times. This student should probably have failed in the middle, but I passed him because his term dates meant that he had to start several weeks late. 2) Make absolutely sure the student has no outside commitments. Mine had an internship that was meant to have finished but kept calling him back. Unfortunately, GNUstep did not really have enough applicants to be able to turn away any that looked even vaguely promising. I don't know how we can go about raising the profile of the projects this year so that we will get more applicants. David ___ 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: Question on NSToolbar
Fred, Please see bug #25236. https://savannah.gnu.org/bugs/index.php?25236 The whole window does resize on Mac OS X when a toolbar is added, not the content view. I attached a test program there and added it's output in a comment to the bug. Thanks, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Fred Kiefer fredkie...@gmx.de To: GNUstep Developer gnustep-dev@gnu.org Sent: Friday, January 2, 2009 4:55:24 PM Subject: Re: Question on NSToolbar Fred Kiefer wrote: Richard Frith-Macdonald wrote: On 30 Dec 2008, at 19:07, Fred Kiefer wrote: I am currently in the process of changing the GNUstep toolbar handling to work on the window decoration view instead of using a separate view to integrate the toolbar. If you are working on that, please could you also look at drawing menus within windows. For development of an mswindows theme, it would be really good if we could have another NSInterfaceStyle for mswindows style menus, and in that case the top level menu view should obviously be placed within the window decoration view, so I'd imagine that doing that would have quite a bit in common with nstoolbar. Yes, this was part of the original concept when I set out to work on that. Currently I am still rather busy with the toolbar code itself, but perhaps I leave that for now as it is and move on to the integration into window decoration. I would expect that we always have the menu as the topmost view in the window, then the toolbar and last the actual contents view. Currently the toolbar increases the size of the window, when switched on. It could as well decrease the size of the contents view. Which should we implement in the future? I just pushed that change out. Please give it a try. Everything related to the in window menu is still missing. What I did was move the toolbar handling from the window to the window decoration view and made that view aware of the toolbar on resizing and when doing size computations. And I changed the code to resize the content view instead of resizing the whole window. I think this is what Apple is doing and it will lead to less flickery displays. This change may break existing applications and it may not in all cases be the changes fault. Please inspect what you get carefully and report back possible improvements. I think I will have to go back to the toolbar code now and improve the drawing code a bit, to me it looks like sometimes it is drawing outside of the view. ___ 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: Question on NSToolbar
Fred, I don't think it's used outside. At least I've never seen it used separately. Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Fred Kiefer fredkie...@gmx.de To: GNUstep Developer gnustep-dev@gnu.org; Quentin Mathé qma...@gmail.com Sent: Tuesday, December 30, 2008 2:07:10 PM Subject: Question on NSToolbar I am currently in the process of changing the GNUstep toolbar handling to work on the window decoration view instead of using a separate view to integrate the toolbar. For this I need to understand a bit more of the current toolbar code and what better way is there to do this than to rewrite that code? Now I stumbled over the split between NSToolbar and GSToolbar. Why is this needed or is it needed at all? In the long run I would like to remove the window ivar on NSToolbar and with that in place there surely is no reason for this separate super class, but even now I cannot find any use of it in the GNUstep code (apart from the ToolbarExample that Quentin pointed to), does it get used outside? ___ 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: Windows look and feel
Windows is hardly a homogenous environment itself. I think a windows theme that is Close enough will suffice in most cases. Think about Java apps or even iTunes and such on Windows. They don't really blend, but they do make enough changes to work with the environment. I think that's really what we should shoot for with respect to a Windows theme/look feel. Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Fred Kiefer fredkie...@gmx.de To: Philippe Bernery philippe.bern...@gmail.com Cc: gnustep-dev@gnu.org Sent: Monday, December 29, 2008 9:22:33 AM Subject: Re: Windows look and feel Philippe Bernery wrote: Fred, what would be different between a windows-ish interface and a real windows interface? I would draw the difference at the point where all the control elements get displayed with naive Windows function calls. Many Windows applications do that themselves and they look out of style. This is also the case with GNUstep applications on Windows no. When using native drawing code, we could improve on that, but there surely will be places where the available Windows controls don't fit our needs. Still, even with native colours, native control drawing, menus inside the window and what ever other adoption will be possible, I would expect that it will always be possible to tell a ported GNUstep application from one that was developed for Windows. ___ 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: Windows look and feel
Well, this is what I thought about. I think having the menu in the window is the first thing to have, then if theming is good, everything should go fine. Yep. Anyway, what you all wrote is good news, I was afraid that GNUstep application would still look like an OpenStep application, I mean with the menu on the left outside the window. Nooo... that would be completely wrong. We do aim to blend to a great degree with most environments via themes. About the Services menu, wouldn't it be better to have it in the systray menu rather than in the menu in the window? What do you think about that? Fred? Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Philippe Bernery philippe.bern...@gmail.com To: Gregory John Casamento greg_casame...@yahoo.com Cc: Fred Kiefer fredkie...@gmx.de; gnustep-dev@gnu.org Sent: Monday, December 29, 2008 5:38:01 PM Subject: Re: Windows look and feel Well, this is what I thought about. I think having the menu in the window is the first thing to have, then if theming is good, everything should go fine. Anyway, what you all wrote is good news, I was afraid that GNUstep application would still look like an OpenStep application, I mean with the menu on the left outside the window. About the Services menu, wouldn't it be better to have it in the systray menu rather than in the menu in the window? What do you think about that? On Mon, Dec 29, 2008 at 4:02 PM, Gregory John Casamento greg_casame...@yahoo.com wrote: Windows is hardly a homogenous environment itself. I think a windows theme that is Close enough will suffice in most cases. Think about Java apps or even iTunes and such on Windows. They don't really blend, but they do make enough changes to work with the environment. I think that's really what we should shoot for with respect to a Windows theme/look feel. Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Fred Kiefer fredkie...@gmx.de To: Philippe Bernery philippe.bern...@gmail.com Cc: gnustep-dev@gnu.org Sent: Monday, December 29, 2008 9:22:33 AM Subject: Re: Windows look and feel Philippe Bernery wrote: Fred, what would be different between a windows-ish interface and a real windows interface? I would draw the difference at the point where all the control elements get displayed with naive Windows function calls. Many Windows applications do that themselves and they look out of style. This is also the case with GNUstep applications on Windows no. When using native drawing code, we could improve on that, but there surely will be places where the available Windows controls don't fit our needs. Still, even with native colours, native control drawing, menus inside the window and what ever other adoption will be possible, I would expect that it will always be possible to tell a ported GNUstep application from one that was developed for Windows. ___ 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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: CYGWIN Problems
Darryl, We are taking a look at adding the option to install on Cygwin back into GNUstep (it previously worked). :) In the meantime you might be interested in the MinGW installers here: http://www.gnustep.org/resources/sources.html#windows The installers should install a basic MinGW system and gnustep core which will allow you to run any programs you like. Thank you for your feedback and your interest in GNUstep. Thanks, Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Darryl Agostinelli dagostine...@gmail.com To: gnustep-dev@gnu.org Sent: Wednesday, December 24, 2008 1:08:44 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. Here's my basic case... Apple has popularized Obj-C and I'd really like to learn it now. But I'm a PC user and don't much want to buy a Mac. Cygwin is the saving grace. I also know about the MiniGW environment, but my very simple Obj-C apps don't work in MiniGW! (i.e. Hello World) Anyhow, I use Cygwin for lots of other stuff and I'm sure others out there do too. So I'm hoping that since Apple is popularizing Obj-C, maybe there will be more PC people like me interested in learning it. And maybe we can kindly pressure your esteemed group to support our favorite unix-like environment for the PC: Cygwin. There are all kinds of problems with trying to use GNUStep on CygWin. Here's a short list: 1) It takes millennia to figure out all the dependencies -- I ran Cygwin setup a dozen times every time I discovered 1 or 2 more. 2) gnustep-startup-0.20.1 has this progressive_mode problem with libJpeg. I see that gnustep-gui-0.16.0 doesn't have that problem, but it's not in gnustep-startup-0.20.1. 3) So I tried to fake out gnustep-startup-0.20.1, by putting in the tar ball for gnustep-gui-0.16.0 and getting rid of the one that comes with gnustep-startup-0.20.1, but that didn't work. I got some error about VERSIONS not being found (see attached log) 4) I also tried to run ./configure on the individual packages like gnustep-gui-0.16.0, but it complains that it can't find install-sh. make doesn't work because it can't find stuff that needs to be created by ./configure. I blew hours on this stuff. Anyhow, I'd love to use your system on Cygwin if you'll be so kind as to make it work well on that. Very kind regards and happy holidays to you all, -D ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Away this weekend
All, I agree. Thank you all for your contributions to this release. I agree with Fred. I think it's going to be a really good one. :) I will have to do a release of Gorm once it's done since there has been a fair amount of work on it as well. Later GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Fred Kiefer fredkie...@gmx.de To: Richard Frith-Macdonald rich...@tiptree.demon.co.uk; gnustep-dev@gnu.org Sent: Friday, December 19, 2008 7:18:52 PM Subject: Re: Away this weekend Me too, back on Monday night. Hopefully the release is already out by then :-) This is going to be a very important release, I would say the best one we ever had. In the release notes of Gui Wolfgang Lux should be mentioned, he fixed plenty of bugs over the last months. Keep he good work coming, Fred Original-Nachricht Datum: Fri, 19 Dec 2008 18:25:38 + Von: Richard Frith-Macdonald rich...@tiptree.demon.co.uk An: GNUstep Developer gnustep-dev@gnu.org Betreff: Away this weekend I'm away this weekend but I've put prerelease code for the next stable release in the stable branch of subversion for people to try out. I've also committed changes intended to ensure that the domain that base is installed into matches the domain it was configured for. This is important if the filesystem configuration used has paths relative to the location of the base library itsself (this is actually the default setup on ms-windows, so it's quote an important case). My code simply reconfigures the base library using the domain that you are trying to install into ... cleverer code would just modify the config for, and rebuild the one file that actually matters ... NSPathUtilities.m , so if anyone wants to produce a better implementation, please do. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a ___ 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 Testfarm Results
Shouldn't the compile farm remove previous installations so that chicken-and-egg dependencies can be detected? Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Adam Fedor [EMAIL PROTECTED] To: Developer GNUstep gnustep-dev@gnu.org Sent: Sunday, December 7, 2008 12:56:02 PM Subject: Re: GNUstep Testfarm Results On Dec 7, 2008, at 10:57 AM, Fred Kiefer wrote: Fail Compile i386-unknown-freebsd6.4 Sun Dec 7 15:38:36 CST 2008 To me the check problem reported here look like the are caused by the recent SYSTEM install change. We could either update the build script to install into SYSTEM again or change the tests. Success Compile sparc-sun-solaris2.7 Sun Dec 7 01:41:22 EST 2008 Success Compile x86_64-unknown-netbsd4.0 Sun Dec 7 03:55:44 CET 2008 Why isn't the same happening here? Probably due to a previous install. I should probably improve that test. ___ 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 DirectFB
Hey Chris, This really does look interesting! Keep us updated on your progress. :) Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Lisbon Acid [EMAIL PROTECTED] To: gnustep-dev@gnu.org Sent: Saturday, December 6, 2008 6:52:06 PM Subject: GNUstep on DirectFB 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. 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. Throw me a line if you are interested. Link: http://picasaweb.google.com/LisbonAcid/GNUstepOnDirectFB# -- christopher [EMAIL PROTECTED] ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base version number
Let me make the changes I made to nib loading a little more stable. I am working on it, and I expect to be done tomorrow. :) After that we should be good for a release. GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Adam Fedor [EMAIL PROTECTED] To: Developer GNUstep gnustep-dev@gnu.org Sent: Monday, November 24, 2008 11:55:00 PM Subject: Re: GNUstep base version number On Nov 23, 2008, at 5:03 AM, Fred Kiefer wrote: PS: What about doing the gui release? That way we can force everybody to recompile :-) And I would like to see Wolfgang's great patches out and getting used. Should I make a release? I was wondering if there had been any more issues with the new NSView code, or if it was stable now. ___ 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: Double initialization of custom (text) views in Gorm files
Wolfgang, These are what are known as designated initializers they are called on objects when a nib is instantiated on instances of custom classes only. This is what is described in Apple's documentation and fits with observed behavior on OpenStep and on Cocoa. If we can find a cleaner implementation for this, then I would suggest that we do that rather than removing the code. Thanks, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Wolfgang Lux [EMAIL PROTECTED] To: gnustep-dev@gnu.org Sent: Thursday, November 20, 2008 4:25:05 PM Subject: Double initialization of custom (text) views in Gorm files The -initWithCoder: method of GSTextViewTemplate in GSNibTemplates invokes the -initWithFrame:textContainer: initializer on self if the custom subclass of NSTextView implements that method. Unfortunately, this leads to a double initialization of instances and, in particular, any customization applied to the text view in the Gorm file will be lost. If anybody is relying on this weird semantics, I just wanted to inform you that I intend to remove that code, since it is definitely wrong (and neither compatible with the Cocoa documentation nor Apple's implementation). The correct way to initialize custom subclasses of NSTextView loaded from a nib file is either via -awakeFromNib or by providing a palette for Interface Builder so that the additional attributes of the custom class can be changed and archived. (Is this possible in Gorm?) Similar code is present in GSViewTemplate, GSTextTemplate, GSMenuTemplate, GSControlTemplate, and GSObjectTemplate and I intend to remove that, too. Wolfgang ___ 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: Double initialization of custom (text) views in Gorm files
Actually, sorry... from looking at this it seems that you're correct: http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaViewsGuide/SubclassingNSView/chapter_6_section_2.html I don't think that anyone is currently relying on that functionality within GNUstep. I might make some of these changes as well so that I can test them a bit and make certain that they reflect what is on Cocoa. Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Gregory John Casamento [EMAIL PROTECTED] To: Wolfgang Lux [EMAIL PROTECTED]; gnustep-dev@gnu.org Sent: Thursday, November 20, 2008 7:44:03 PM Subject: Re: Double initialization of custom (text) views in Gorm files Wolfgang, These are what are known as designated initializers they are called on objects when a nib is instantiated on instances of custom classes only. This is what is described in Apple's documentation and fits with observed behavior on OpenStep and on Cocoa. If we can find a cleaner implementation for this, then I would suggest that we do that rather than removing the code. Thanks, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Wolfgang Lux [EMAIL PROTECTED] To: gnustep-dev@gnu.org Sent: Thursday, November 20, 2008 4:25:05 PM Subject: Double initialization of custom (text) views in Gorm files The -initWithCoder: method of GSTextViewTemplate in GSNibTemplates invokes the -initWithFrame:textContainer: initializer on self if the custom subclass of NSTextView implements that method. Unfortunately, this leads to a double initialization of instances and, in particular, any customization applied to the text view in the Gorm file will be lost. If anybody is relying on this weird semantics, I just wanted to inform you that I intend to remove that code, since it is definitely wrong (and neither compatible with the Cocoa documentation nor Apple's implementation). The correct way to initialize custom subclasses of NSTextView loaded from a nib file is either via -awakeFromNib or by providing a palette for Interface Builder so that the additional attributes of the custom class can be changed and archived. (Is this possible in Gorm?) Similar code is present in GSViewTemplate, GSTextTemplate, GSMenuTemplate, GSControlTemplate, and GSObjectTemplate and I intend to remove that, too. Wolfgang ___ 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: Double initialization of custom (text) views in Gorm files
Wolfgang, I've commited a fix for this. Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Gregory John Casamento [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED]; Wolfgang Lux [EMAIL PROTECTED]; gnustep-dev@gnu.org Sent: Thursday, November 20, 2008 8:04:11 PM Subject: Re: Double initialization of custom (text) views in Gorm files Actually, sorry... from looking at this it seems that you're correct: http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaViewsGuide/SubclassingNSView/chapter_6_section_2.html I don't think that anyone is currently relying on that functionality within GNUstep. I might make some of these changes as well so that I can test them a bit and make certain that they reflect what is on Cocoa. Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Gregory John Casamento [EMAIL PROTECTED] To: Wolfgang Lux [EMAIL PROTECTED]; gnustep-dev@gnu.org Sent: Thursday, November 20, 2008 7:44:03 PM Subject: Re: Double initialization of custom (text) views in Gorm files Wolfgang, These are what are known as designated initializers they are called on objects when a nib is instantiated on instances of custom classes only. This is what is described in Apple's documentation and fits with observed behavior on OpenStep and on Cocoa. If we can find a cleaner implementation for this, then I would suggest that we do that rather than removing the code. Thanks, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Wolfgang Lux [EMAIL PROTECTED] To: gnustep-dev@gnu.org Sent: Thursday, November 20, 2008 4:25:05 PM Subject: Double initialization of custom (text) views in Gorm files The -initWithCoder: method of GSTextViewTemplate in GSNibTemplates invokes the -initWithFrame:textContainer: initializer on self if the custom subclass of NSTextView implements that method. Unfortunately, this leads to a double initialization of instances and, in particular, any customization applied to the text view in the Gorm file will be lost. If anybody is relying on this weird semantics, I just wanted to inform you that I intend to remove that code, since it is definitely wrong (and neither compatible with the Cocoa documentation nor Apple's implementation). The correct way to initialize custom subclasses of NSTextView loaded from a nib file is either via -awakeFromNib or by providing a palette for Interface Builder so that the additional attributes of the custom class can be changed and archived. (Is this possible in Gorm?) Similar code is present in GSViewTemplate, GSTextTemplate, GSMenuTemplate, GSControlTemplate, and GSObjectTemplate and I intend to remove that, too. Wolfgang ___ 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: Time for a new stable release of base?
I submitted my test for the @synchronize changes. Nothing from my end should hold up a release. Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Adam Fedor [EMAIL PROTECTED] To: gnustep-dev@gnu.org Developer gnustep-dev@gnu.org Sent: Tuesday, November 11, 2008 10:27:06 AM Subject: Re: Time for a new stable release of base? On Nov 11, 2008, at 4:50 AM, Richard Frith-Macdonald wrote: Anyone object if I make a 1.16.4 stable release of the base library to make recent bugfixes available (and perhaps a 1.17.1 unstable release too, so make sure the latest unstable release has all the fixes of the latest stable release)? Is there anything this should be waiting for? I think that's great. I would want to make a stable/unstable release of the other libraries as well (and make). ___ 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
GNUstep SCALE Attendance
All, Is anyone available to go to SCALE in California? For those who don't know SCALE is the (S)outhern (CA)lifornia (L)inux (E)xpo, it's website is: http://scale7x.socallinuxexpo.org/. I would really like for us to have a presence there. The new WindowMaker guys have said that they are willing to share a booth with us, which would be really cool. At any rate... as it turns out, I may indeed be able to attend as well. I would like to get the word out there that we are still around and that we're active. So, if you're in CA and you're interested in GNUstep, let me know if you would like to attend. select * from people where state = 'CA' and interested_in_gnustep = 'Y' and lives_close_enough = 'Y' and has_time = 'Y'; (Geek humor) ;) Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: New icns loading code
Hi Matt, It's good to hear from you! :) Yes, I think we would like to discuss this. Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Mathew Eis [EMAIL PROTECTED] To: gnustep-dev@gnu.org Sent: Monday, October 13, 2008 10:00:19 PM Subject: Re: New icns loading code Hi, I just came across your message on the list... I am the primary developer of the libicns code, and also the projects current maintainer. I would hate for you to have to re-do so much work with the icns loading. Would it help if we changed the library's licensing to the LGPLv3? Please CC me in your reply, I am not part of the GnuStep Dev list. -Mathew Eis -snip- Why not just use libicns? It is published with the GPL 2 licence, which may not be suitable for some projects using GNUstep. -/snip- ___ 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: xib plists
Hey David, I have thought about what it might take to do this. Essentially, this would mean a new set of encoders, similar to what is done with GModel and Keyed Archiving (although Keyed Archiving uses the same methods as regular encoding). Currently there's so much to do in GNUstep that this is not something that I personally can take on at the moment, but it is something that I would be happy to advise others in doing (i.e. I could give guidance and pointers along the way based on my experiences). Since Gorm's internal data structure is separate from it's file format now, it would be a matter of writing a plugin and a library which would contain the categories which would implement the new encoder. My feeling is that this would be something like GSXibArchiver or something like that (just an example for a name...) and it would have methods like initWithXibEncoder:/encodeWithXibEncoder: etc. It would need to have a category for every known class in GNUstep in order to work properly. Anyway... those are my thoughts on the subject and about the extent of how much I've done on it. You know now as much as I do about how we're going to do this, if it's done. :) Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: David Chisnall [EMAIL PROTECTED] To: GNUstep Developer gnustep-dev@gnu.org Sent: Monday, October 13, 2008 1:12:48 PM Subject: xib plists Hi, Since 10.5, OS X has used .xib files, which contain an XML format which is similar in content to a .nib file. These are then transformed in to .nib files when the project is compiled. The ibtool program which performs this conversion can also translate them into plist format, with class hierarchy, object properties, connections and classes all stored as dictionaries. I wonder if anyone has looked at importing and exporting this format from GORM? David ___ 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: New icns loading code
I had to make one minor fix, but otherwise it works fine. Thanks. GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: GNUstep Developer gnustep-dev@gnu.org Sent: Wednesday, September 3, 2008 3:46:30 AM Subject: New icns loading code I just committed a change to gui that adds some basic icns loading even when libicns is not present on a system. Even with that code in place libicns will be the better solution in many case. Why not just use libicns? - It is published with the GPL 2 licence, which may not be suitable for some projects using GNUstep. - It is currently not shipped with my Linux distribution. My implementation has been done without looking at the libicns code, just by following there documentation and Gregs usage of their functions. I also added some ideas found in Nikolaus Schallers myStep implementation of icns loading. The code I added has many limitations, which are probably not even worth fixing, as we should be using libicns for the more complex cases. There are also a few bugs (something that looks like an of by one case for 128 bit images), these surely need fixing. I also changes Gregs loading code a bit, as it was leaking memory and could not load any icns file that didn't have a 48x48 representation. Somebody needs to check that this still works with libicns. 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
Re: more licensing issues :(
I'm hoping it is too. I'm removing the GNUstep_Images_Copyright file and mentioning his email in the comment. GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Hubert Chathi [EMAIL PROTECTED] To: gnustep-dev@gnu.org Sent: Sunday, June 22, 2008 10:17:49 AM Subject: Re: more licensing issues :( On Sat, 21 Jun 2008 13:15:48 -0700 (PDT), Gregory John Casamento [EMAIL PROTECTED] said: All, I don't think we have an issue as Andrew has agreed to license them under the GPL. ... Excellent. Thanks for looking into this, Gregory. I hope this is the last of the licensing issues, and that we can all get back to coding. ;) Hubert ___ 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: more licensing issues :(
I think this is a good idea. Let me see what the response from Andrew is first. Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Nicolas Roard [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: Developers list for the Étoilé desktop environment [EMAIL PROTECTED]; Jesse Ross [EMAIL PROTECTED]; Hubert Chathi [EMAIL PROTECTED]; gnustep-dev@gnu.org Sent: Saturday, June 21, 2008 9:37:08 AM Subject: Re: more licensing issues :( On Fri, Jun 20, 2008 at 11:40 PM, Gregory John Casamento [EMAIL PROTECTED] wrote: GNUstep has been moved back to GPLv2+ so those licensing issues should be taken care of. I will contact Andrew and see what can be done about this. Thank you for pointing this out. Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Hubert Chathi [EMAIL PROTECTED] To: gnustep-dev@gnu.org Sent: Friday, June 20, 2008 1:51:51 PM Subject: more licensing issues :( Debian Bug #487143 [1] was filed against gnustep-gui, which points out that some of the included images are licensed in a way that prevents modification, and also prevents use for anything other than developing free OpenStep applications. [1] http://bugs.debian.org/487143 This presents a problem since Debian requires that everything in the distribution, including images, sounds, data files, documentation, be freely modifiable, and so this could result in GNUstep being removed from Debian. I should note that this license only applies to certain images: namely the images used for drawing various GUI controls such as checkboxes, etc. Is it possible to get these images relicensed? Maybe we could replace those icons by jesse's icons ?.. -- Nicolas Roard I love deadlines. I like the whooshing sound they make as they fly by. -- Douglas Adams ___ 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: more licensing issues :(
GNUstep has been moved back to GPLv2+ so those licensing issues should be taken care of. I will contact Andrew and see what can be done about this. Thank you for pointing this out. Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Hubert Chathi [EMAIL PROTECTED] To: gnustep-dev@gnu.org Sent: Friday, June 20, 2008 1:51:51 PM Subject: more licensing issues :( Debian Bug #487143 [1] was filed against gnustep-gui, which points out that some of the included images are licensed in a way that prevents modification, and also prevents use for anything other than developing free OpenStep applications. [1] http://bugs.debian.org/487143 This presents a problem since Debian requires that everything in the distribution, including images, sounds, data files, documentation, be freely modifiable, and so this could result in GNUstep being removed from Debian. I should note that this license only applies to certain images: namely the images used for drawing various GUI controls such as checkboxes, etc. Is it possible to get these images relicensed? Thanks Hubert P.S. The link listed in the license: http://www.gnustep.org/UserSuite/UserSuite.html doesn't work. P.P.S. There are additional reasons that I believe that the current license is unreasonable. If anyone is interested, ask me. ___ 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 apps segfault on AMD64
I used SuSE for a while and had a similar issue. I thought that, by now, SuSE would have resolved it's 64 bit issues, but I see that's not the case. *sighs* GNUstep works fine on Debian when compiled 64-bit, so this is definitely something that is distro-specific. I'll see what I can do to test this and determine what can be done. When I used SuSE compiling GNUstep as 32 bit worked fine for me. If you can do that, it should solve the problem for now until we can fix the problem on SuSE. GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Tim Schmielau [EMAIL PROTECTED] To: gnustep-dev@gnu.org Sent: Thursday, June 19, 2008 11:28:44 AM Subject: GNUstep apps segfault on AMD64 I have two quad core 64 bit Xeon machines with SLES 10 sharing the same home directory where a fresh GNUstep installation (startup 0.20.0), gcc-4.2.4 and libffi libraries reside. On one of the machines, GNUstep runs fine, on the other one every GNUstep application I've tried so far segfaults. For example, Gorm gives hal:~ gdb GNUstep/System/Applications/Gorm.app/Gorm GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-suse-linux...Using host libthread_db library /lib64/libthread_db.so.1. (gdb) r Starting program: ~/GNUstep/System/Applications/Gorm.app/Gorm [Thread debugging using libthread_db enabled] [New Thread 47638148492048 (LWP 11571)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47638148492048 (LWP 11571)] 0x009a04d8 in ?? () (gdb) bt #0 0x009a04d8 in ?? () #1 0x2b539d4ab0a6 in -[NSDistributedNotificationCenter(Private) _connect] (self=0x987b60, _cmd=0x2b539d950130) at NSDistributedNotificationCenter.m:780 #2 0x2b539d4a974d in -[NSDistributedNotificationCenter addObserver:selector:name:object:suspensionBehavior:] (self=0x987b60, _cmd=0x2b539d950100, anObserver=0x984760, aSelector=0x2b539d2799d0, notificationName=0x0, anObject=0x2b539d2782e0, suspensionBehavior=NSNotificationSuspensionBehaviorCoalesce) at NSDistributedNotificationCenter.m:339 #3 0x2b539d4a942b in -[NSDistributedNotificationCenter addObserver:selector:name:object:] (self=0x987b60, _cmd=0x2b539d2799e0, anObserver=0x984760, aSelector=0x2b539d2799d0, notificationName=0x0, anObject=0x2b539d2782e0) at NSDistributedNotificationCenter.m:264 #4 0x2b539ce66021 in -[_GSWorkspaceCenter init] (self=0x984760, _cmd=0x2b539d973850) at NSWorkspace.m:275 #5 0x2b539d4f7d8e in +[NSObject new] (self=0x2b539d2796e0, _cmd=0x2b539d2798e0) at NSObject.m:1301 #6 0x2b539ce66f04 in -[NSWorkspace init] (self=0x982f40, _cmd=0x2b539d2799b0) at NSWorkspace.m:634 #7 0x2b539ce66d24 in +[NSWorkspace sharedWorkspace] (self=0x2b539d279500, _cmd=0x2b539d1cf230) at NSWorkspace.m:603 #8 0x2b539cd36d22 in -[NSDocumentController init] (self=0x97edd0, ---Type return to continue, or q return to quit--- _cmd=0x2b539d2abdd0) at NSDocumentController.m:207 #9 0x2b539cec7f15 in -[GSNibItem initWithCoder:] (self=0x97cdf0, _cmd=0x2b539d99f350, aCoder=0x969220) at GSNibTemplates.m:567 #10 0x2b539d56c90f in -[NSUnarchiver decodeValueOfObjCType:at:] ( self=0x969220, _cmd=0x2b539d91e950, type=0x2b539d5f1035 @, address=0x7fff0ea8fcb0) at NSUnarchiver.m:649 #11 0x2b539d40c965 in -[GSSet initWithCoder:] (self=0x97c390, _cmd=0x2b539d99f350, aCoder=0x969220) at GSSet.m:233 #12 0x2b539d56c90f in -[NSUnarchiver decodeValueOfObjCType:at:] ( self=0x969220, _cmd=0x2b539d2ac0c0, type=0x2b539cf1ef49 @, address=0x97b258) at NSUnarchiver.m:649 #13 0x2b539cec6cab in -[GSNibContainer initWithCoder:] (self=0x97b230, _cmd=0x2b539d99f350, aCoder=0x969220) at GSNibTemplates.m:405 #14 0x2b539d56c90f in -[NSUnarchiver decodeValueOfObjCType:at:] ( self=0x969220, _cmd=0x2b539d9395b0, type=0x2b539d6ae6a4 @, address=0x7fff0ea90040) at NSUnarchiver.m:649 #15 0x2b539d45a49a in -[NSCoder decodeObject] (self=0x969220, _cmd=0x2b539d2c2430) at NSCoder.m:216 #16 0x2b539cee85af in -[GSGormLoader loadModelData:externalNameTable:withZone:] (self=0x967c50, _cmd=0x2b539d2c24e0, data=0x968f30, context=0x7841c0, zone=0x2b539d9b6b40) at GSGormLoader.m:74 #17 0x2b539cee895c in -[GSGormLoader loadModelFile:externalNameTable:withZone:] (self=0x967c50, _cmd=0x2b539d1a27b0, fileName=0x967b00, context=0x7841c0, ---Type return to continue, or q return to quit--- zone=0x2b539d9b6b40) at GSGormLoader.m:134 #18 0x2b539ccee204 in +[NSBundle(NSBundleAdditions) loadNibFile:externalNameTable:withZone:] (self=0x2b539d932580, _cmd=0x2b539d1a28b0,
Re: Next stable release?
I believe we should shoot for this, yes. So you think we should target the end of the month to make the release? Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: gnustep-dev@gnu.org Sent: Thursday, June 5, 2008 3:11:34 PM Subject: Next stable release? Following on David's email, It's been over a year since we last branched a stable release. Should we try to do another one soon? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
I'm not sure, but I defer to Fred's judgement entirely on this. But my opinion is that If we do deprecate it, it should not be removed for a while. The reason is that the xlib/x11 backend is a good fallback position to have when all else fails. Additionally, on older machines, the xlib backend is the only thing that's useful since the art and/or cairo backends may be somewhat slow on them. Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: David Chisnall [EMAIL PROTECTED] To: Fred Kiefer [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Richard Frith-Macdonald [EMAIL PROTECTED]; gnustep-dev@gnu.org Sent: Friday, June 6, 2008 7:20:33 AM Subject: Re: Next stable release? On 6 Jun 2008, at 09:05, Fred Kiefer wrote: Richard Frith-Macdonald wrote: On 5 Jun 2008, at 20:11, [EMAIL PROTECTED] wrote: Following on David's email, It's been over a year since we last branched a stable release. Should we try to do another one soon? I guess so. I really wanted to get base much more compatible with the latest MacOS-X before doing another stable release, but I just haven't had the time to do any real work on that, so realistically it's not worth waiting. I don't see any reason at all not to make a new stable release of gui/back, but perhaps Fred knows differently. A new stable release is fine for me. I think the current code is far better then the 0.12 release and I don't see any mayor incompatibility change coming up in the near future. There is one thing I should do before a new back release, that is test with cairo 1.6.4 to see how to avoid the black bars that have been reported. I hope to do this on the weekend, after that a release should be possible. Just one more question: Are we all confident that the big changes I made to NSWindow and GSLayoutManager are now stable enough? They work perfectly for me, but that isn't a real test. 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. David ___ 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: NSWindow NSGraphicsContext issue
Please, let's move this entire discussion to the bug tracker here: https://savannah.gnu.org/bugs/index.php?23336 Thanks, GJC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: gnustep-dev@gnu.org Sent: Friday, May 23, 2008 6:45:58 AM Subject: Re: NSWindow NSGraphicsContext issue Original-Nachricht On Thu, 22 May 2008, Gregory John Casamento wrote: Given that Fabien said once he recreated the .gorm file it's not happening anymore and also that I can't make it happen in any other application, I believe we can consider this issue a non-issue. Is this true Fabien? I am currently away from my computer and cannot test this, but from looking at the code in NSWindow, GSClassSwaper and GSWindowTemplate I would still expect that initWithContentRect:... gets called twice on the same NSWindow object. (BTW, shouldn't GSClassSwapper release self in initWithCoder:, when returning the new object?) Greg, I understand it is hard to reproduce this without a proper example, but please try to look at the code and see what it does. One note for the future, however. I would really like everyone to start using the bug reporting system a little more. This helps us tackle bugs and enhancement requests to meet your desires for GNUstep faster since it is more easily tracked and is in one place as opposed to emails, IMs, private messages on IRC, etc. My fault. I will try to use it :) In this case it was also my fault. I should have put the remaining issue into our bug tracker, but it was so late at night, when I finally had your program more or less working. When I am back at my computer I will try to reproduce the problem with a tiny Gorm file and report it, if it still exists. Fred -- Super-Acktion nur in der GMX Spieleflat: 10 Tage für 1 Euro. Über 180 Spiele downloaden und spiele: http://flat.games.gmx.de ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSWindow NSGraphicsContext issue
I'll try that one. I had downloaded another version, but I think it's the same. Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developer gnustep-dev@gnu.org Sent: Tuesday, May 20, 2008 4:34:53 AM Subject: Re: NSWindow NSGraphicsContext issue Strange, I get the log message as soon as I open an image from the ToyViewer open menu entry. The ToyViewer version I am using is this one: http://www.sonappart.net/TV.tar.bz2 Hope this helps Fred Gregory John Casamento wrote: I've tried to recreate this issue. I am not seeing the NSLog that was added come up once during my tests either when running the application (ToyViewer) or any other apps. I'm continuuing to look into it. I'm going to open a bug on this so that the progress can be tracked there. GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Gregory John Casamento [EMAIL PROTECTED] To: Fred Kiefer [EMAIL PROTECTED]; GNUstep Developer gnustep-dev@gnu.org Sent: Monday, May 19, 2008 4:34:49 PM Subject: Re: NSWindow NSGraphicsContext issue Fred, I will take a look at this as soon as possible.The solution should allow existing gorm files to be handled properly as well as correct the problem going forward. GJC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: GNUstep Developer gnustep-dev@gnu.org Sent: Sunday, May 18, 2008 7:26:06 PM Subject: Re: NSWindow NSGraphicsContext issue I was able to resolve most of the problems I listed below by not using autorelease objects. There still is one issue and it is an important one. When creating an NSWindow from a Gorm file the initialization is called twice. This will result in two backend objects being created for the window and one of them would leak and the window map would stay in an inconsistent state, after the window is freed. I was able to hack around this, by adding a check for an already existing _windowNum into initWithContentRect:styleMask:backing:defer:screen:. This only prevents part of the problem and a real fix would be not to have an NSWindow (or a subclass) in a Gorm file at all. For NIB files we already us NSWindowTemplate instead of GSWindowTemplate and this prevents the problem. Could somebody with a deeper understanding of Gorm please look into this issue? Fred Fred Kiefer wrote: Last week I tried to resolve a circular refernce problem between NSWindow and NSGraphicsContext. The source of the problem is that when an NSWindow gets displayed it generates an NSGraphicsContext (or rather a subclass) which will then manage all the actual drawing. The window retain the context and the context has an info dictionary which includes the window. That way we already start off with a circular reference. To break this I released the window once, to adjust the retain count. Now when the window gets deallocated I first do a retain on it and then release the graphics context which will in turn result in a release on the window. Or so I hoped. There were a few issues with my original code. The graphics context and the dictionary where autorelease objects, so I had to postpone the deallocation of the window by returning from dealloc and let it be called again. This also needed a bit of isa sizzling as subclasses will not be aware of that reference counting trick and wont be prepared to get dealloc called twice. (And the code in NSWindow dealloc needed to be reentrant as well) With that all resolved I expected my code now to work correctly, but this still isn't the case. As it turns out, calling retain on an object that already was about to get released wont have the expected result. When a release is send to an object with a retain count of 1, that count wont be changed! Now this means that I have to differentiate between calls to _termianteWindow that come from dealloc, where I don't call the retain and calls for oneShot windows, where I need to increase the retain count before freeing the context. All of this now looks like an even bigger mess then the one I started with and now any help on how to clearly solve this would be welcome. Cheers, Fred PS: Some of the code I talk about above is still not committed. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSWindow NSGraphicsContext issue
I'm apparently missing something,... I get an error trying to compile that. Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developer gnustep-dev@gnu.org Sent: Tuesday, May 20, 2008 4:34:53 AM Subject: Re: NSWindow NSGraphicsContext issue Strange, I get the log message as soon as I open an image from the ToyViewer open menu entry. The ToyViewer version I am using is this one: http://www.sonappart.net/TV.tar.bz2 Hope this helps Fred Gregory John Casamento wrote: I've tried to recreate this issue. I am not seeing the NSLog that was added come up once during my tests either when running the application (ToyViewer) or any other apps. I'm continuuing to look into it. I'm going to open a bug on this so that the progress can be tracked there. GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Gregory John Casamento [EMAIL PROTECTED] To: Fred Kiefer [EMAIL PROTECTED]; GNUstep Developer gnustep-dev@gnu.org Sent: Monday, May 19, 2008 4:34:49 PM Subject: Re: NSWindow NSGraphicsContext issue Fred, I will take a look at this as soon as possible.The solution should allow existing gorm files to be handled properly as well as correct the problem going forward. GJC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: GNUstep Developer gnustep-dev@gnu.org Sent: Sunday, May 18, 2008 7:26:06 PM Subject: Re: NSWindow NSGraphicsContext issue I was able to resolve most of the problems I listed below by not using autorelease objects. There still is one issue and it is an important one. When creating an NSWindow from a Gorm file the initialization is called twice. This will result in two backend objects being created for the window and one of them would leak and the window map would stay in an inconsistent state, after the window is freed. I was able to hack around this, by adding a check for an already existing _windowNum into initWithContentRect:styleMask:backing:defer:screen:. This only prevents part of the problem and a real fix would be not to have an NSWindow (or a subclass) in a Gorm file at all. For NIB files we already us NSWindowTemplate instead of GSWindowTemplate and this prevents the problem. Could somebody with a deeper understanding of Gorm please look into this issue? Fred Fred Kiefer wrote: Last week I tried to resolve a circular refernce problem between NSWindow and NSGraphicsContext. The source of the problem is that when an NSWindow gets displayed it generates an NSGraphicsContext (or rather a subclass) which will then manage all the actual drawing. The window retain the context and the context has an info dictionary which includes the window. That way we already start off with a circular reference. To break this I released the window once, to adjust the retain count. Now when the window gets deallocated I first do a retain on it and then release the graphics context which will in turn result in a release on the window. Or so I hoped. There were a few issues with my original code. The graphics context and the dictionary where autorelease objects, so I had to postpone the deallocation of the window by returning from dealloc and let it be called again. This also needed a bit of isa sizzling as subclasses will not be aware of that reference counting trick and wont be prepared to get dealloc called twice. (And the code in NSWindow dealloc needed to be reentrant as well) With that all resolved I expected my code now to work correctly, but this still isn't the case. As it turns out, calling retain on an object that already was about to get released wont have the expected result. When a release is send to an object with a retain count of 1, that count wont be changed! Now this means that I have to differentiate between calls to _termianteWindow that come from dealloc, where I don't call the retain and calls for oneShot windows, where I need to increase the retain count before freeing the context. All of this now looks like an even bigger mess then the one I started with and now any help on how to clearly solve this would be welcome. Cheers, Fred PS: Some of the code I talk about above is still not committed. ___ 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: NSWindow NSGraphicsContext issue
I've tried to recreate this issue. I am not seeing the NSLog that was added come up once during my tests either when running the application (ToyViewer) or any other apps. I'm continuuing to look into it. I'm going to open a bug on this so that the progress can be tracked there. GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Gregory John Casamento [EMAIL PROTECTED] To: Fred Kiefer [EMAIL PROTECTED]; GNUstep Developer gnustep-dev@gnu.org Sent: Monday, May 19, 2008 4:34:49 PM Subject: Re: NSWindow NSGraphicsContext issue Fred, I will take a look at this as soon as possible.The solution should allow existing gorm files to be handled properly as well as correct the problem going forward. GJC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: GNUstep Developer gnustep-dev@gnu.org Sent: Sunday, May 18, 2008 7:26:06 PM Subject: Re: NSWindow NSGraphicsContext issue I was able to resolve most of the problems I listed below by not using autorelease objects. There still is one issue and it is an important one. When creating an NSWindow from a Gorm file the initialization is called twice. This will result in two backend objects being created for the window and one of them would leak and the window map would stay in an inconsistent state, after the window is freed. I was able to hack around this, by adding a check for an already existing _windowNum into initWithContentRect:styleMask:backing:defer:screen:. This only prevents part of the problem and a real fix would be not to have an NSWindow (or a subclass) in a Gorm file at all. For NIB files we already us NSWindowTemplate instead of GSWindowTemplate and this prevents the problem. Could somebody with a deeper understanding of Gorm please look into this issue? Fred Fred Kiefer wrote: Last week I tried to resolve a circular refernce problem between NSWindow and NSGraphicsContext. The source of the problem is that when an NSWindow gets displayed it generates an NSGraphicsContext (or rather a subclass) which will then manage all the actual drawing. The window retain the context and the context has an info dictionary which includes the window. That way we already start off with a circular reference. To break this I released the window once, to adjust the retain count. Now when the window gets deallocated I first do a retain on it and then release the graphics context which will in turn result in a release on the window. Or so I hoped. There were a few issues with my original code. The graphics context and the dictionary where autorelease objects, so I had to postpone the deallocation of the window by returning from dealloc and let it be called again. This also needed a bit of isa sizzling as subclasses will not be aware of that reference counting trick and wont be prepared to get dealloc called twice. (And the code in NSWindow dealloc needed to be reentrant as well) With that all resolved I expected my code now to work correctly, but this still isn't the case. As it turns out, calling retain on an object that already was about to get released wont have the expected result. When a release is send to an object with a retain count of 1, that count wont be changed! Now this means that I have to differentiate between calls to _termianteWindow that come from dealloc, where I don't call the retain and calls for oneShot windows, where I need to increase the retain count before freeing the context. All of this now looks like an even bigger mess then the one I started with and now any help on how to clearly solve this would be welcome. Cheers, Fred PS: Some of the code I talk about above is still not committed. ___ 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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: AppKit (Win32) generals questions
Okay... cool. I was unsure about this. Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: David Chisnall [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: Thierry DELHAISE [EMAIL PROTECTED]; gnustep-dev@gnu.org Sent: Thursday, May 8, 2008 9:16:11 AM Subject: Re: AppKit (Win32) generals questions On 8 May 2008, at 14:10, Gregory John Casamento wrote: The only issue with using the standard panels is accessory views, since there's no way for them to be shown in the standard panel. I've mentioned this before, but the Win32 API explicitly does allow this. You can reserve a region of one of the standard dialogs for drawing your own controls in. If GNUstep on Win32 supports drawing an NSView into an arbitrary Win32 window then accessory views are really not hard to add. Having them interact with the selection in the main part is slightly harder but not impossible. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: AppKit (Win32) generals questions
Richard, We should probably put this in the FAQ someplace since the question regarding using Win32 controls comes up relatively often. I've found it necessary to explain this to a number of people in the past. Later, GJC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Richard Frith-Macdonald [EMAIL PROTECTED] To: Thierry DELHAISE [EMAIL PROTECTED] Cc: Gregory John Casamento [EMAIL PROTECTED]; gnustep-dev@gnu.org Sent: Thursday, May 8, 2008 1:16:24 PM Subject: Re: AppKit (Win32) generals questions On 8 May 2008, at 15:04, Thierry DELHAISE wrote: Gregory John Casamento a écrit : Thierry, GNUstep can be made to have a native win32 look through the use of themes. Great ! But ... this is not enought and this is my fault (sorry) since I've asked about look and should not have to. What I want is that my Application be a Native win32 application using MS Windows application recommendations : using of standards panel, alowing interaction with clipboard, and Windows services (ODBC, COM, OLE) , Windows toolbar's, etc ...So what I want , is that GNUstep be a layer between my application code and Win32. That's roughly what GNUstep is supposed to be ... but it's a little more complex than that Currently there is no plan for using the standard panels. This would be a welcome change, since it would help GS blend into the OS better. Yes, I saw, and this is where I can may be contribute to the project but with the directions/recommendations of some old steppers ;-) (let call them gurus ! ;-) ). After spending my morning time to dig into GNUstep implementation I've some (certainly stupid) questions about how is port GNUstep on Win32 : So on Win32, the concept of DisplayServer have been port ? What was the functionnal need for this, I mean for Win32 ? It seems to me (but may be I'm wrong) that the display server have the functionnal job to draw all (GNUstep) windows inside an application. So, DisplayServer is in charge of drawing low level window letting gnustep gui drawing all controls with the look of GNUsetp since gui don't use native control on win32 (?). It seems too that it have to handle drag and drop operations and may be clipboard interaction ? Why not have let this jobs to operating system ? Since on win32 windows could do the jobs ? (I know that win32 do mostly bad job ;-) but this one, since it do it since so many years, we can hope it will do it mostly correctly ;-), no ? The GNUstep GUI code is divided into two library ... the gui proper (gnustep-gui), which handles most of the work of implementing the AppKit API, and the backend (gnustep-back) which handles the interface to the native operating system. The display server (GSDispalyServer) is the class which provides the main interface between the two parts. So code in gnustep-gui calls methods in the display server, and code in gnustep-back translates them to native calls of the system you are running on. This means that application developers use the OpenStep/GNUstep/MacOS- X AppKit API to write their applications, and the gnustep-back library uses the native functionality to do the job where possible. For instance, you do cut and paste or DnD using the OpenStep API for that, and the actual calls to perform the operations are the native windows ones. ie we do leave the job to the operating system. Of course, where the two APIs (OpenStep and win32) operate in very different ways, the conversion between the two is hard, but often the layer between the two is quite thin. One area where there is not much scope for overlap is drawing within a window ... the way that the OpenStep API operates is so different that high level code for drawing things inside a windows using the native operating system generally cannot fit with OpenStep, so the gui library does all the drawing inside the window with quite low level code rather than trying to map OpenStep 'controls' to native 'widgets'. In this area, does controls in the spirit of GNUstep have to be draw by GNUstep or could those be the native one's ? This questions since I pretty sure that developping a Win32 theme could spent a lot of time to recreate the exact look and feel (and function) of an allready existing control under the native platform. And I'm not sure (but may be I'm wrong) that Mac's users, or *nix one's want to have a win32 native look on their host platform ? I know that *Step one's want to remember the good day's ... so I understand why there is a need to draw controls or windows or menus with *Step look and feel in mind ;-) (my Sun's OpenStep workstation died last years ... ;-) ) Well, the amount of use of native controls can be quite variable. The basic design of the two libraries is, to draw OpenStep controls rather than try to map to native
Re: GPLv2 licensing issues
The FSF has offered to give a temporary exception, but it's tentative at the moment. I will get back with more information soon. Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Hubert Chathi [EMAIL PROTECTED] To: gnustep-dev@gnu.org Sent: Wednesday, April 30, 2008 6:58:17 PM Subject: Re: GPLv2 licensing issues On Fri, 11 Apr 2008 16:14:57 -0700 (PDT), Gregory John Casamento [EMAIL PROTECTED] said: All, I've written Brett Smith at the FSF to ask about exceptions or any possible solutions to the issues we're discussing. I will post relevant points when he replies to my email. Any news on this? Have the developers reached a consensus on what to do with the licensing issues? Hubert ___ 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: GSoC participant
Matt, I would like to personally welcome you and the other GSoC participants who have decided to work on GNUstep. We're excited about your involvement and look forward to your contributions. :) Please don't hesitate to ask questions to your mentors, or to other members of the GNUstep team, if you need to. Welcome. :) Thanks, GJC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Matt Ball [EMAIL PROTECTED] To: gnustep-dev@gnu.org Sent: Wednesday, April 23, 2008 11:32:23 AM Subject: Re: GSoC participant Hi all, I'm yet another GSoC participant. My project will mostly consist of factoring the drawing code for all controls out of the control classes themselves and into an external resource in order to provide consistent theming. If time allows, I'll also be working on implementing an additional theme using the win32 APIs to allow for a consistent appearance on Windows. As for a short bit about myself, I'm a 19 year old undergrad at UCLA, majoring in Computer Science and Engineering. This will be my first official contribution to an open source group, but I've been coding on my own for roughly the last 10 years. Nowadays, I mostly specialize in Cocoa development, so GNUStep is certainly a good fit! Anyway, I just wanted to briefly introduce myself and let everyone know what I'll be working on. Thanks, and good luck to all other GSoC participants! - Matt Ball ___ 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
Pending Gorm release...
I will be releasing Gorm in the next few days, if not tonight. Please take the time to test the SVN version of Gorm to make certain that it works properly and report any bugs you find. My apologies for the delay, I've become very busy at work. Thanks, Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: bindings and Renaissance
One thing that springs immediately to mind is the connector classes for Binding. They have to be finished. Are you going to be using these in Renaissance? Do you currently use the existing connector classes? Mostly curious. :) GJC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Xavier Glattard [EMAIL PROTECTED] To: Nicola Pero [EMAIL PROTECTED] Cc: Xavier Glattard [EMAIL PROTECTED]; Fred Kiefer [EMAIL PROTECTED]; gnustep-dev@gnu.org Sent: Saturday, March 29, 2008 9:08:24 AM Subject: Re: bindings and Renaissance Selon Nicola Pero [EMAIL PROTECTED]: In bindings.gsmarkup i define 2 textFields. First i bind the 1st field to the 2nd one : [first bind:value toObject:second ...] If i change the value of the 1st field, the 2nd one is updated. But I expected that the value of the 1st would be updated when the value of the 2nd one changes. To get that behavior i have to bind the 2nd field to the first. [second bind:value toObject:first ...] I think that is the expected behaviour. At least it was what I implemented :-) Yes, on Apple Mac OS X it seems to work in the same way. :-) I'm quite suprised that an Apple made class is not KVC compliant. But i may have miss something. Thank you for the test :-) Xavier ___ 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: bindings and Renaissance
Aren't you effectively writing code when you create the XML by hand? Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Xavier Glattard [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: Xavier Glattard [EMAIL PROTECTED]; Nicola Pero [EMAIL PROTECTED]; Fred Kiefer [EMAIL PROTECTED]; gnustep-dev@gnu.org Sent: Saturday, March 29, 2008 6:28:52 PM Subject: Re: bindings and Renaissance Selon Gregory John Casamento [EMAIL PROTECTED]: One thing that springs immediately to mind is the connector classes for Binding. They have to be finished. Are you going to be using these in Renaissance? Do you currently use the existing connector classes? Mostly curious. :) GJC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer I don't currently use any other connector, i'm new to Renaissance, but i'll work on it. Well... i'm lazy Renaissance is a tool to build a gui without code. Bindings are tools to bind a gui to a model without code. I'm looking to Core Data that is a tool to build model without code. So : yes i would like to use Bindings in Renaissance. I would like to get a full RAD environment with GNUstep that allows to build an application without... you know what. Only XML. And if i really need some code i might use steptalk. Xavier, lazy dreamer ^_^ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r26307 - /libs/gui/trunk/Source/NSApplication.m
The change wasn't to the return type, but to what it's being compared to in the method. We changed the declaration of a local variable to BOOL so that the comparison would be done properly. You want this changed back? Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Riccardo Mottola [EMAIL PROTECTED] Cc: GNUstep Developer gnustep-dev@gnu.org Sent: Wednesday, March 26, 2008 5:03:55 AM Subject: Re: [Gnustep-cvs] r26307 - /libs/gui/trunk/Source/NSApplication.m Riccardo Mottola wrote: Author: rmottola Date: Sun Mar 16 02:02:52 2008 New Revision: 26307 URL: http://svn.gna.org/viewcvs/gnustep?rev=26307view=rev Log: changed terminate type to BOOL since it is one and the value froma delegate got wrongly cast Modified: libs/gui/trunk/Source/NSApplication.m No it is not. The return value of applicationShouldTerminate: is of type NSApplicationTerminateReply and has been this since some time. It used to be a BOOL in OpenStep. Could you please undo your change that prevents the value of NSTerminateLater from being passed on and we may check together what did go wrong in your original delegate. 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
Re: FW: Continuous Buttons
I tested continuous buttons in Gorm last night, it works properly. GJC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Nicola Pero [EMAIL PROTECTED] To: Fred Kiefer [EMAIL PROTECTED] Cc: Herbo [EMAIL PROTECTED]; gnustep-dev@gnu.org Sent: Friday, March 14, 2008 12:59:17 PM Subject: Re: FW: Continuous Buttons Quick question. Does GNUstep support continuous button presses? It seem when I push a GUI button (NSButton) the GUI freezes until it's released. I haven't tested it myself, but continuous buttons should work, when you set them up correctly. Sliders aren't too much different and there the continuous action works. What is needed is the proper setup, which means to set the sendActionOn: value to a suitable value. At least this should be the right solution. OK/yes :-) Herbo, I added continuous and sendActionOn attributes to Renaissance's buttons (and generally controls) on trunk and they seem to work fine. :-) 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
Re: Release critical bug in NSToolbarItem
Fred,
Please go ahead and put this into the bug tracking system. I'm working on
Gorm some today, so I suspect I'll bump into this once I update a little later
on. I might take a look at it and pull in Quentin if I can.
Gregory Casamento -- Principal Consultant - OLC, Inc
# GNUstep Chief Maintainer
- Original Message
From: Fred Kiefer [EMAIL PROTECTED]
To: GNUstep Developer gnustep-dev@gnu.org
Sent: Saturday, March 8, 2008 5:09:15 AM
Subject: Release critical bug in NSToolbarItem
I just found a critical bug that needs to be fixed before we do a new
gui release. Not sure if this warning is needed, but sometimes Adam is
really quick with new releases :-)
The problem gets triggered by a patch I recently made to NSCell. Now the
control sendAction:to: methods gets called even when there is no action
set. This was needed for KVB compatibility with Apple and in itself this
is not the problem it just reveals a longer standing issue.
In NSToolbar we now get the following loop:
#6 0xb7b975f7 in -[NSCell performClickWithFrame:inView:] (
self=0x8886070, _cmd=0xb7daa9a0, cellFrame=
{origin = {x = 0, y = 0}, size = {width = 61, height = 61}},
controlView=0x88854e8) at NSCell.m:1399
#7 0xb7b91553 in -[NSButtonCell performClickWithFrame:inView:] (
self=0x8886070, _cmd=0xb7dbca00, cellFrame=
{origin = {x = 0, y = 0}, size = {width = 61, height = 61}},
controlView=0x88854e8) at NSButtonCell.m:1486
#8 0xb7bc179a in -[NSControl performClick:] (self=0x88854e8,
_cmd=0xb7e25240, sender=0x8593da8) at NSControl.m:811
#9 0xb7cc7dc5 in -[NSToolbarItem _setSelected:] (self=0x8593da8,
_cmd=0xb7e5c438, selected=1 '\001') at NSToolbarItem.m:1471
#10 0xb7d620a9 in -[GSToolbar setSelectedItemIdentifier:] (
self=0x8881930, _cmd=0xb7e24f98, itemIdentifier=0xb7f59a58)
at GSToolbar.m:845
#11 0xb7cc2fdd in -[GSToolbarButton sendAction:to:] (self=0x88854e8,
_cmd=0xb7daea20, action=0x0, target=0x85dfb40) at NSToolbarItem.m:363
#12 0xb7b97719 in -[NSCell performClickWithFrame:inView:] (
self=0x8886070, _cmd=0xb7daa9a0, cellFrame=
{origin = {x = 0, y = 0}, size = {width = 61, height = 61}},
controlView=0x88854e8) at NSCell.m:1407
#13 0xb7b91553 in -[NSButtonCell performClickWithFrame:inView:] (
self=0x8886070, _cmd=0xb7dbca00, cellFrame=
{origin = {x = 0, y = 0}, size = {width = 61, height = 61}},
This didn't happen before as most toolbar items don't have an action
set, so this path wasn't reached. What wee need to do now is to break
this loop. I suspect that we should not be calling performClick: in the
_setSelected: method on NSToolbarItem, but then I am not familiar with
that code and don't know where the performClick: call really belongs.
Is there anybody out there with more knowledge on NSToolbar willing to help?
___
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: Summer of Code 2008
Yes. :) Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Lars Sonchocky-Helldorf [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: Fred Kiefer [EMAIL PROTECTED]; GNUstep Developer gnustep-dev@gnu.org Sent: Friday, March 7, 2008 4:48:55 PM Subject: Re: Summer of Code 2008 Is someone taking care of this? Regards, Lars Am 03.03.2008 um 22:54 schrieb Gregory John Casamento: I think SoC would be a good thing to get into this year. We need to gain momentum and SoC is a good way to get the word out as well as get some people interested in GNUstep. Later, GJC -- Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: GNUstep Developer gnustep-dev@gnu.org Sent: Monday, March 3, 2008 4:19:06 PM Subject: Summer of Code 2008 I just noticed that application for Google's Summer of Code started today. We have until 12th of March to submit our application as mentoring organization. I am not saying that we have to, the result from the projects last year were a bit below of what we expected. On the other hand, in the end the KVO and KVB code that was done during SoC started our implementation in that area. Without that it might have taken us another year to even look at it. 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 ___ 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: Next release
Adam/Fred, One of the things I think we need to do in order to address the ABI compatibility issue is to adopt a strategy similar to what Apple has done in it's headers. Currently there is a lot of space which is marked as reserved in Apple's header files. This allows for future additions without changing the memory layout of the class which is what leads to ABI issues and subsequently the need for recompilation. This would allow older versions of applications to continue to function with newer versions of the core libraries even after a modification where some of the reserved space has been consumed. The trick is to reserve just the right amount of space so that you don't make your classes needlessly big and so that you adequately anticipate the future growth of some. Another potential solution to this problem, a bit different from the one above and probably a little risky is to simply have a void pointer in each class' ivar section and have it point to the appropriate structure when initialized during runtime. This would allow the ABI to be stable since the class' foot print would always be the size of the void pointer. The structure could then be changed to our hearts content without need to worry about ABI compatibility issues at all. The drawback to this one is that it's a major undertaking to implement it and, it's, potentially hazardous. The third option is to get gui to a point where it's ABI is actually stable. Consider that base hasn't changed much for a long time. This is because it's been at 1.0 for a very long time and because it is truly stable. There are a myriad of things we need to focus on in gui at this point before we can, rightfully, call it a 1.0 release. Printing is the one thing that I think is most prominent on my mind regarding gui at this point. Printing is incomplete. Last time I started up TextEdit.app or Ink.app and typed and tried to print a page, it came out blank. This could be a configuration issue, or it could be something else, I don't know.. if it is, please tell me. :) Anyway... I'll come back later and we can discuss what gui 1.0 should be. :) Later, GJC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Adam Fedor [EMAIL PROTECTED] Cc: Developer GNUstep gnustep-dev@gnu.org Sent: Tuesday, March 4, 2008 1:37:49 PM Subject: Re: Next release Adam Fedor wrote: On Mar 3, 2008, at 1:40 PM, Riccardo wrote: A newer stable release should be done indeed. Adam? That's up to Gregory, et. al. Do we have any goals for the next stable release? gui 1.0? I am still a bit reluctant to use the version number 1.0. We would be committing us to stay ABI compatible from then on and we are not ready for that. Using the number 0.14.0 would be fine for me. (I already have a proposal for ABI stability, I just need time to write it up and then find somebody to implement it :-) 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
Re: Summer of Code 2008
I think SoC would be a good thing to get into this year. We need to gain momentum and SoC is a good way to get the word out as well as get some people interested in GNUstep. Later, GJC -- Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: GNUstep Developer gnustep-dev@gnu.org Sent: Monday, March 3, 2008 4:19:06 PM Subject: Summer of Code 2008 I just noticed that application for Google's Summer of Code started today. We have until 12th of March to submit our application as mentoring organization. I am not saying that we have to, the result from the projects last year were a bit below of what we expected. On the other hand, in the end the KVO and KVB code that was done during SoC started our implementation in that area. Without that it might have taken us another year to even look at it. 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
Re: amd64 and libffi
I'm seeing a similar failure on my x86_64 (essentially amd64) machine. Could either of you send a backtrace? Thanks, GJC -- Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Pete French [EMAIL PROTECTED] To: gnustep-dev@gnu.org; [EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 11:29:25 AM Subject: Re: amd64 and libffi I got a report from a Debian user that GNUstep programs segfault on the amd64 architecture when gnustep-base is compiled with libffi. (On the other hand, GNUstep programs apparently don't work with ffcall on Opterons, since ffcall doesn't seem to play well with the NX bit, apparently.) Unfortunately, I don't have an amd64 to try things out for myself. Does anyone have any experience with libffi under amd64? I've just switched (yesterday) to an amd64 based desktop at work - currently I can't get GNUstep running att all :-( Am using ffcall here, I havent tried with libffi yet. Does anyone have GNustep running under amd64 ? ___ 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: amd64 and libffi
DO works just fine. -- Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Thomas Gamper [EMAIL PROTECTED] To: gnustep-dev@gnu.org Sent: Tuesday, February 26, 2008 12:52:27 PM Subject: amd64 and libffi Hi! I am running GNUstep on amd64, for the time being I had no problems. There were a couple warnings during compile (pointersize differences) of the core packages and Gorm. Probabyl that's something that has to be adressed in future. I don't recall which of ffi or ffcall I used, I will give details to tomorrow, since I don't have an amd64 machine here at home. During the next couple of weeks I intend to start using DO eventually, so I think I will run into trouble regarding amd64 and foreign function calls. How's the actual status of DO in GNUstep? TOM I got a report from a Debian user that GNUstep programs segfault on the amd64 architecture when gnustep-base is compiled with libffi. (On the other hand, GNUstep programs apparently don't work with ffcall on Opterons, since ffcall doesn't seem to play well with the NX bit, apparently.) Unfortunately, I don't have an amd64 to try things out for myself. Does anyone have any experience with libffi under amd64? I've just switched (yesterday) to an amd64 based desktop at work - currently I can't get GNUstep running att all :-( Am using ffcall here, I havent tried with libffi yet. Does anyone have GNustep running under amd64 ? -Inline Attachment Follows- ___ 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 desktop?
Fred, I think I will need to discuss this with him to set it straight. It needs to be made clear to him what our direction is. GJC -- Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: GNUstep Developer gnustep-dev@gnu.org Sent: Friday, January 4, 2008 11:44:38 AM Subject: GNUstep desktop? In the LWN issue of December 13th I found a mentioning of GNUstep and a link to the GNU page where RMS recommends the GNUstep live CD: http://www.gnu.org/links/links.html#FreeGNULinuxDistributions It surely is nice to get mentioned there, but the Live CD is already a bit outdated and the words used by RMS may not go well with all GNUstep developers: GNUstep, a GNU/Linux distribution using the GNUStep desktop. Its initial purpose was to serve as a free implementation of the OpenStep framework. RMS himself is taking great care that everybody else in the world is using the term GNU/Linux instead of just Linux and he even showed up at our stall at the FOSDEM to set a poor Etoile developer straight who had used the world Linux. Perhaps our project leader should contact RMS and tell him about the difficulties of using GNUstep and desktop as a single phrase? No retaliation of course, just getting the message across. If RMS wont understand what GNUstep is, how could we ever teach the rest of the world? ___ 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: Key Value Observation is over reacting
Fred, I don't believe you've overlooked anything. What you're describing seems to me, to be the right behavior. GJC -- Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: GNUstep Developer gnustep-dev@gnu.org Sent: Thursday, December 13, 2007 12:34:34 PM Subject: Key Value Observation is over reacting While testing key value binding I found a problem with the current KVO code. When an object is starting to get watched a new class gets cooked up to handle the set calls on the object. Here all setter methods get overridden, which is fine, as we don't want to change the class when another key on the same object gets watched and this also allows to reuse the new class for other objects. But some of the replaced methods just don't are setters, even if the look like. This later leads to a problem when the corresponding getter is called and none exists. Here we should at least check, if a getter exists and only then treat the method as a setter. Is it OK, to change that code or is there something I overlooked? 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
Getting to 1.0 for gui
All, I'd like to have a discussion and come to a consensus on what everyone feels would comprise a 1.0 gui release. Please let me know your thoughts on the matter. Thanks, GJC -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release
Yes, the only thing from my perspective is that I would like to make sure that we're okay releasing with the files that we discussed (the one's from WindowMaker). -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: Adam Fedor [EMAIL PROTECTED]; Developer GNUstep gnustep-dev@gnu.org Sent: Monday, November 5, 2007 12:03:42 PM Subject: Re: Next GNUstep release As far as I can tell 21478 is resolved now and 21479 is only a wish. From my side there isn't any other outstanding issue blocking a release. I will stop my development work now and wait for the release. Fred Gregory John Casamento wrote: I would like to resolve 21478/21479 and make sure that they are not gui related prior to doing the release of gui. GJC -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer - Original Message From: Adam Fedor [EMAIL PROTECTED] To: Developer GNUstep gnustep-dev@gnu.org Sent: Tuesday, October 30, 2007 10:25:13 AM Subject: Re: Next GNUstep release On Oct 29, 2007, at 5:30 PM, Fred Kiefer wrote: gui and back are now ready for the next release. The license version has now been changed for all files with FSF copyright assignment, I did not touch the other files. I also added some release information for the upcoming release. Who is going to handle the actual release process and what should happen to make? As far as I remember there was only one tiny issue fixed in make. The only reason for a release would be the license switch. I could make the release for the libraries when everything's ready. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release
Yeah, I believe we should be okay. I don't think anything is holding back the release at this moment. I've moved Gorm to GPLv3 now. Later, GJC -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer - Original Message From: Adam Fedor [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: Developer GNUstep gnustep-dev@gnu.org Sent: Monday, November 5, 2007 2:24:37 PM Subject: Re: Next GNUstep release I think it's fine, given that, if anyone really did have a problem with it, we could easily rewrite them. On Nov 5, 2007, at 11:39 AM, Gregory John Casamento wrote: Yes, the only thing from my perspective is that I would like to make sure that we're okay releasing with the files that we discussed (the one's from WindowMaker). -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: Adam Fedor [EMAIL PROTECTED]; Developer GNUstep gnustep- [EMAIL PROTECTED] Sent: Monday, November 5, 2007 12:03:42 PM Subject: Re: Next GNUstep release As far as I can tell 21478 is resolved now and 21479 is only a wish. From my side there isn't any other outstanding issue blocking a release. I will stop my development work now and wait for the release. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release
I would like to resolve 21478/21479 and make sure that they are not gui related prior to doing the release of gui. GJC -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer - Original Message From: Adam Fedor [EMAIL PROTECTED] To: Developer GNUstep gnustep-dev@gnu.org Sent: Tuesday, October 30, 2007 10:25:13 AM Subject: Re: Next GNUstep release On Oct 29, 2007, at 5:30 PM, Fred Kiefer wrote: gui and back are now ready for the next release. The license version has now been changed for all files with FSF copyright assignment, I did not touch the other files. I also added some release information for the upcoming release. Who is going to handle the actual release process and what should happen to make? As far as I remember there was only one tiny issue fixed in make. The only reason for a release would be the license switch. I could make the release for the libraries when everything's ready. ___ 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: Gorm issues and next GNUstep core releases
I'm aware of this problem and I'm planning on looking into it tonight. GJC -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer - Original Message From: Quentin Mathé [EMAIL PROTECTED] To: GNUStep Developers gnustep-dev@gnu.org Sent: Monday, October 29, 2007 7:42:27 PM Subject: Gorm issues and next GNUstep core releases Hi, From recent Fred's commits, I just saw that the next gnustep-gui release is on the way. That's great :-) However previous Gorm release crashes with -gui trunk, and Gorm trunk although it doesn't crash anymore has several issues that makes it difficult to use. These issues weren't present in Gorm 2.1, so I think they result from recent gnustep-gui changes and fixing them in a clean manner might involve modifying gnustep-gui. That's why I would like to suggest delaying next core releases until they are fixed. May be all these issues can be fixed directly in Gorm though?… in this case my suggestion is pointless. The issues I discuss are: - https://savannah.gnu.org/bugs/?21402 - view control points (knots) are invisible most of time, this means problems for selecting container subviews and resizing views For this last issue, I have a detailed bug report on the way, I still need to test and write down the expected behavior for each kind of control. Cheers, Quentin. -- Quentin Mathé [EMAIL PROTECTED] ___ 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: Objective-C 2.0 and other new features in Leopard
Fred, The previous email wasn't meant to address anything outside of how ObjC 2.0 directly impacts GNUstep. Nor was it meant to cast an optimistic or, indeed, pessimistic slant on things. Neither is this one, for that matter. That being said, you and I have discussed the these very issues last time we spoke. We need to figure out how to solve them. The development applications and libraries in GNUstep are complete for the most part. All of the important classes are there and, with Gorm and Project Center, all of the important functionality is there. I think that part of what we're seeing is due to that. The perception is that there is not much left to do on the core libraries themselves. Here are the challenges that I see (in order of priority): 1) Applications... We need a comprehensive suite of applications for GNUstep. Something that, when someone uses them they have an integrated experience. We currently don't have that. 2) GUI... Apologies to anyone who's in love with the old interface and you know who you are, it's extremely dated. Etoile is helping with that, but many people, when they try GNUstep.. they try the core project and they see the old NeXTSTEP-ish GUI. This GUI is not as attractive as some of the current GUIs out there. We need to make it so. A pretty gui can be very compelling to both users AND developers. 3) Repository... I think we need to simplify a number of things with respect the repository. It is currently hard for people to check GNUstep out because of the structure it was given in SVN. You can't simply follow the instructions on the GNA website to make it work but you need to checking from devmodules. We should be able to put something into the repository which will let people check out in a more normal fashion. 4) Thinking differently... In my experience GNUstep is often perceived as doing things differently or weirdly because we don't follow the current standards. Usually, these standards are set by people who are using C++ or C based libraries which are no where near as dynamic as what GNUstep has to offer. Honestly, call me an idealist, byt I think that the way we do things is often better both in execution and design. From how our make system works to Gorm to how the backend works. GNUstep is a better system than GNOME or KDE in it's design. However.. all of that being said... when we do things differently, it might be useful for us to determine if there is a way to bridge the gap. We've already taken steps towards addressing #4 earlier this way with Nicola's changes with gnustep-make-2.0 (for which kudos are long overdue... he did an excellent job.. thank you Nicola) since they allow for installing GNUstep in different layouts... including one that is FHS compliant, but we need more. Also... we should emphasize *publically* what we've done more than we do. In the past two years we have been ahead of Apple twice or more in a number of things: 1) 64 bit support on Intel. GNUstep had this way before Apple did! 2) AppKit on openmoko -- while the iPhone debuts with a pitiful API... we have a full AppKit available! 3) Support for multiple model formats! last I checked Apple only supports .nib files for Cocoa/Carbon (and the second is being dropped). These are not optimism but statements of fact. It's too late to say anything about the first one, but it's certainly not too late to talk about 2 and 3. We have a lot of challenges ahead of us. Please tell me your thoughts on these points. Later, GJC -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developers gnustep-dev@gnu.org Sent: Monday, October 29, 2007 8:09:32 PM Subject: Re: Objective-C 2.0 and other new features in Leopard This is a very optimistic view of things, which I cannot share for the whole of GNUstep at the moment. My feeling is the race is over and we lost. Apple has just released a shining new version of there system and GNUstep is rather stagnant. We are no longer attracting old or new developers and it doesn't look like this is going to change. Have a look at the Changelog files from the last half year and you will understand what I mean. Not even the paid coders from GSoC made any difference. We urgently need to change the way GNUstep appears to the outside world, or we will become as obsolete as now seem. Personally I am thinking about reducing my involvement with GNUstep. It still is fun to hack way on GNUstep, but trying to get the library out of its current stagnation phase would require a bigger effort, which I cannot see at the moment. Cheers, Fred Gregory John Casamento wrote: All, As many of you are probably aware, Apple released Leopard today. Leopard contains a number of enhancements which are important to us, one of which is Objective-C 2.0
Objective-C 2.0 and other new features in Leopard
All, As many of you are probably aware, Apple released Leopard today. Leopard contains a number of enhancements which are important to us, one of which is Objective-C 2.0. Objective-C 2.0 = Odds are the existing developers will still write for versions of Mac OS 10.4 and below in order to have the widest possible range of customers, but eventually Objective-C 2.0 *will* become the standard. As more and more people upgrade this will become the case sooner rather than later. The core libraries of GNUstep should remain ObjC 1.0 compatible for the forseeable future, but I believe we need to start talking to the people in the GCC project to determine how we can help with the implementation of a gnu runtime that works with the new version of the language. Interface Builder enhancements = The other feature which is interesting in it is the ability of InterfaceBuilder to support multiple languages including Ruby. The recursive descent parser I wrote for Gorm currently only handles Objective-C headers. Additionally, Gorm's internal data structures are decoupled from the type of archive that is being saved or read, nib, or gorm. When I added the nib support I rewrote nib/gorm support in both gui and in Gorm to support an architecture that allows classes which read/write different types of gui files to register themselves so that they would be considered when a gui model is loaded. I am planning on moving Gorm to a more bundle/plugin oriented architecture in the future. This has a number of implications: Gorm will be able to: 1) parse multiple languages 2) generate multiple languages (for class files) 3) read/write any type of gui model for which it has a plugin available * gorm * nib * gmodel... etc Regards, -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep GUI/Back release
I'm going to create a GPLv3 status page so that people know what to help with for that. Right now, I think we're pretty close. GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: GNUstep Developer gnustep-dev@gnu.org Sent: Monday, September 10, 2007 9:57:51 AM Subject: Next GNUstep GUI/Back release First some background: I will be starting a new job in October and most likely wont have as much time for GNUstep from then on. In addition for the last two weeks of September, I will be on holidays without much internet access. The current week is the last, where I have plenty of time for GNUsteps coding. If we aren't able to motivate some new programmers for gui and back, progress will slow down for these modules. But since the last GNUstep release there have been quite some changes to these modules. The cairo backend is now almost usable and gui has been cleaned up and brought closer to MacOSX. This process isn't completed but the results should already be a huge improvement over previous GNUstep releases. What I would like to do now is fix some new introduced bugs (NSSplitView comes up strangely, the cursor bug has reappeared) and give the current code a good testing and after that, come up with a new GNUstep base, gui and back release. (A base release is needed for the error recovery header) Does this schedule, release by mid/end October, fit your? Attached you find my statistics on 10.4 compatibility of the GNUstep header files. One outstanding issue is the change to LGPL 3, here I still have an unfinished new version of xdnd that will need some more work. If nobody takes up this task (I could send my files), it wont make it into the next release. This means, at least back still needs to ship with LGPL 2. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
New GUI Library Maintainer: Fred Kiefer
All, I discussed this with Fred yesterday and he agreed to be the maintainer of the GUI library for GNUstep. I can't think of anyone I trust more with this job than him. Congratulations, Fred. :) Later, GJC -- Gregory CasamentoGNUstep Cheif Gorm Maintainer ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: FYI and a few questions...
Stefan, This is exciting news. I'm glad to hear you're working on such a thing. Since it seems as though your other questions have been adequately answered, I will offer a few suggestions: 1) You may want to look at the code for InnerSpace before creating something from scratch.InnerSpace is the GNUstep successor to the original BackSpace application on NeXTSTEP/OPENSTEP. It is compliant with BackSpace's API and it supports BackSpace modules with minimal changes. 2) Also, please stay away from names such as gs* as such things are trite and overused. 3) Also, I don't believe that a screen saver tool should go into the GNUstep main project. It should likely go into a separate project, such as GAP, Etoile or it's own project outside of the main project. Apologies to Riccardo, but he is mistaken InnerSpace's purpose is to be both a way of providing an animated background AND a screen saver. The challenges I faced with InnerSpace were: 1) How to make it not eat up CPU cycles like crazy and 2) how to make it omnipresent (i.e. appearing on all desktops) in a *PORTABLE* way. Both are solvable problems, but, at the time I wrote InnerSpace I had too many other things (read Gorm, GUI, Nib compatibility... etc) to concentrate on. ;) Later, GJC -- Gregory Casamento - Original Message From: Riccardo [EMAIL PROTECTED] To: Stefan Bidigaray [EMAIL PROTECTED] Cc: GNUstep Developers gnustep-dev@gnu.org Sent: Friday, July 27, 2007 1:12:43 PM Subject: 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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Moving to GPLv3
Yes. What is your suggestion? We could try to write our own xdnd.m file, implementing features of xdnd 5. I might just do that. I agree. Like you've suggested, we should use this as an opportunity to re-write it to use the latest standard. Later, GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developers gnustep-dev@gnu.org Sent: Thursday, July 12, 2007 6:18:17 AM Subject: Re: Moving to GPLv3 Gregory John Casamento wrote: Status of back == Tools - font_cacher LGPL2 and includes directly a file with LGPL2 Is the included file that is LGPL2 assigned to the FSF? Yes, this is a compile time copy of a file used in the xlib backend. No problem when we leave this tool as LGPL and probably even OK, when we change it to GPL. gpbs GPL2, includes a file with LGPL 2 which could be removed without loosing functionality Same concern as above... if the answer is no, then we should consider removing the code. I need to ask the FSF what we need to do for libraries or code that is GPLv2 that is in the GNUstep repository, but is not assigned to the FSF. No, here we don't have the copyright. It is the xdnd.c mentioned below. After reading through the code again I am no longer sure whether we still need part of the XDnD implementation or not. I know for sure that the part, where we try to provide data was wrongly placed here. The code in pasteboardChangedOwner belongs into XDDragView and is already there. To give a better educated answer here, I would need to recheck all the DnD code and some old discussions with Wim. But we need a solution for the xdnd.c file any as it is also used in the x11 code. Source -- Mostly our own LGPL 2 code with copyright by the FSF. okay. In x11 we link with xdnd.c which has LGPL2 or later but copyright: Copyright (C) 1998 Paul Sheer. Hmmm... this one we need to discuss. Yes. What is your suggestion? We could try to write our own xdnd.m file, implementing features of xdnd 5. I might just do that. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Moving to GPLv3
Fred, I'm going to respond to these one by one: Status of back == Tools - font_cacher LGPL2 and includes directly a file with LGPL2 Is the included file that is LGPL2 assigned to the FSF? gpbs GPL2, includes a file with LGPL 2 which could be removed without loosing functionality Same concern as above... if the answer is no, then we should consider removing the code. I need to ask the FSF what we need to do for libraries or code that is GPLv2 that is in the GNUstep repository, but is not assigned to the FSF. Source -- Mostly our own LGPL 2 code with copyright by the FSF. okay. In x11 we link with xdnd.c which has LGPL2 or later but copyright: Copyright (C) 1998 Paul Sheer. Hmmm... this one we need to discuss. The files from wraster also have LGPL2 or later and copyright: Copyright (c) 1997-2002 Alfredo K. Kojima. Are these files that were taken from WindowMaker? I was of the understanding the WindowMaker is also a GNU project, but I could be mistaken. For the old xdps backend we have one file with (c) Copyright 1991-1994 Adobe Systems Incorporated. I believe, at this point, we can declare the xdps backend pretty much dead. It relies on DGS which is no longer under development. I won't turn this into a discussion of the merits of such a system... that's really for another thread. Status of gui = Tools - All GPL2 or later and copyright by FSF. Excellent. ColorPickers All GPL2 but should maybe be LGPL2. Depending on how we view bundles. I believe that this is correct. Bundles can be viewed like libraries. I'm not sure how the FSF would interpret this since they are essentially linked at runtime. I believe it's better to err on the side of caution and make it LGPL. Model - nib2gmodel is LGPL2 or later. Perhaps this should be GPL2. The rest is also LGPL2 or later. Okay. Source -- NSBezierPath contains a bit of code based on code with LGPL2 or later from Libart_LGPL - library of basic graphic primitives Copyright (C) 1998 Raph Levien. I don't think this will be an issue, but I'll look into it. The rest still needs to be checked. Very good, excellent work... thanks. My suggestion would be to put everything in gui and back into LPGL even tools and bundles. This will make the reuse of code a lot easier. I would like to see what the other maintainers say with respect to doing this before making any final decisions to universally move everything to LGPL. I will need to get into the specifics of some of the cases that you mention to determine if everything is okay for the move. Thanks very much, -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developers gnustep-dev@gnu.org Sent: Wednesday, July 11, 2007 11:58:48 AM Subject: Re: Moving to GPLv3 Gregory John Casamento wrote: All, I am going to start reviewing those parts of GNUstep that I am a direct contributor to for movement to the GPLv3 or LGPLv3 where appropriate, namely gnustep-gui and Gorm. Fred, please help me look at gui for any issues regarding this move. I believe for those packages it will be simple. I would like all of the maintainers for other parts of GNUstep to do the same and report back if there are any issues with moving to the new license. I expect that the transition will be smooth. Status of back == Tools - font_cacher LGPL2 and includes directly a file with LGPL2 gpbs GPL2, includes a file with LGPL 2 which could be removed without loosing functionality Source -- Mostly our own LGPL 2 code with copyright by the FSF. In x11 we link with xdnd.c which has LGPL2 or later but copyright: Copyright (C) 1998 Paul Sheer. The files from wraster also have LGPL2 or later and copyright: Copyright (c) 1997-2002 Alfredo K. Kojima. For the old xdps backend we have one file with (c) Copyright 1991-1994 Adobe Systems Incorporated. Status of gui = Tools - All GPL2 or later and copyright by FSF. ColorPickers All GPL2 but should maybe be LGPL2. Depending on how we view bundles. Model - nib2gmodel is LGPL2 or later. Perhaps this should be GPL2. The rest is also LGPL2 or later. Source -- NSBezierPath contains a bit of code based on code with LGPL2 or later from Libart_LGPL - library of basic graphic primitives Copyright (C) 1998 Raph Levien. The rest still needs to be checked. My suggestion would be to put everything in gui and back into LPGL even tools and bundles. This will make the reuse of code a lot easier. 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
Re: Project Center status, or lack thereof...
Sergii, It looks like you've made some excellent progress. I completely understand being busy, since I'm in the middle of a bout of very busy RL work myself. If anyone would like to volunteer to help Serge maintain PC it would be greatly appreciated. I believe that a new release, especially with the features you mention, would be good. As I said before, I've been considering moving forward with implementation of the feature in Gorm to connect to and communicate with PC, just like Xcode and IB do on the Mac currently. I believe that this could provide a more cohesive experience for users that want to use PC and could also provide a way for outside IDE's to integrate with Gorm as well. Thanks, GJC -- Gregory Casamento - Original Message From: Sergii Stoian [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developers gnustep-dev@gnu.org Sent: Monday, July 9, 2007 8:04:00 AM Subject: Re: Project Center status, or lack thereof... Hello, Gregory. Actually some time ago I've got huge amount of work in real life. So I'll also want to see somebody providing maintanance of ProjectCenter. I'll try to continue working on PC as my real life job let me do it. My apologies to GNUstep community for silence about PC development status. Let me put some information about what is already done in SVN for upcoming 0.5.0 release of PC (excerpt from ANNOUNCE): * Added new project types Framework and Resource Set. * Implemented on demand loading of bundles (project types, editor). * Impemented localization support for projects. * Some user interface ehnancements were made (save restore geometry of subviews in project window splitview, drag and drop for icons). * Clicking on .m and .h file in project browser expands to file structure (classes, methods). * Incorporated ProjectManager's editor with some modifications. Syntax color highlighting works. * Rewritte bundle loading mechanizm. All bundle now loaded on demand. * All windows and panels are now GORM files. * Fixes for MingW environment (thanks to Adam Fedor). * Support for separate build directory added. On 7/8/07, Gregory John Casamento [EMAIL PROTECTED] wrote: All, I would like to get this fixed at some point. PC is one of our core applications and it should work with the latest release, but yet it's not gnustep-make 2.0 compliant which, basically, renders it useless. See this comment: As can be seen, I did not create a ProjectCenter packages because the current release ( 0.4.3) does not work with make 2.0! I do request that a new version be release to conform to the current make release. I've been thinking lately about plans to integrate Gorm and ProjectCenter... to have better communication between them.I would prefer to have someone to work with on this instead of doing it all myself as my work load for my company has increased dramatically lately (yes... running a consulting company takes time and effort). My sincerest apologies to Serge, but I would appreciate it if anyone who is interested in maintaining PC would let me know. Thanks, GJC -- Gregory Casamento -- Sergii Stoian, ProjectCenter maintainer ___ 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: Project Center status, or lack thereof...
Sergi, Did you incorporate code directly from PM? Let me know. Thanks, GJC -- Gregory Casamento - Original Message From: Sergii Stoian [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developers gnustep-dev@gnu.org Sent: Monday, July 9, 2007 8:04:00 AM Subject: Re: Project Center status, or lack thereof... Hello, Gregory. Actually some time ago I've got huge amount of work in real life. So I'll also want to see somebody providing maintanance of ProjectCenter. I'll try to continue working on PC as my real life job let me do it. My apologies to GNUstep community for silence about PC development status. Let me put some information about what is already done in SVN for upcoming 0.5.0 release of PC (excerpt from ANNOUNCE): * Added new project types Framework and Resource Set. * Implemented on demand loading of bundles (project types, editor). * Impemented localization support for projects. * Some user interface ehnancements were made (save restore geometry of subviews in project window splitview, drag and drop for icons). * Clicking on .m and .h file in project browser expands to file structure (classes, methods). * Incorporated ProjectManager's editor with some modifications. Syntax color highlighting works. * Rewritte bundle loading mechanizm. All bundle now loaded on demand. * All windows and panels are now GORM files. * Fixes for MingW environment (thanks to Adam Fedor). * Support for separate build directory added. On 7/8/07, Gregory John Casamento [EMAIL PROTECTED] wrote: All, I would like to get this fixed at some point. PC is one of our core applications and it should work with the latest release, but yet it's not gnustep-make 2.0 compliant which, basically, renders it useless. See this comment: As can be seen, I did not create a ProjectCenter packages because the current release ( 0.4.3) does not work with make 2.0! I do request that a new version be release to conform to the current make release. I've been thinking lately about plans to integrate Gorm and ProjectCenter... to have better communication between them.I would prefer to have someone to work with on this instead of doing it all myself as my work load for my company has increased dramatically lately (yes... running a consulting company takes time and effort). My sincerest apologies to Serge, but I would appreciate it if anyone who is interested in maintaining PC would let me know. Thanks, GJC -- Gregory Casamento -- Sergii Stoian, ProjectCenter maintainer ___ 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: Project Center status, or lack thereof...
I believe that this is worth looking into at this point. -- Gregory Casamento - Original Message From: Yen-Ju Chen [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developers gnustep-dev@gnu.org Sent: Sunday, July 8, 2007 1:03:21 PM Subject: Re: Project Center status, or lack thereof... On 7/7/07, Gregory John Casamento [EMAIL PROTECTED] wrote: All, I would like to get this fixed at some point. PC is one of our core applications and it should work with the latest release, but yet it's not gnustep-make 2.0 compliant which, basically, renders it useless. See this comment: As can be seen, I did not create a ProjectCenter packages because the current release ( 0.4.3) does not work with make 2.0! I do request that a new version be release to conform to the current make release. I've been thinking lately about plans to integrate Gorm and ProjectCenter... to have better communication between them.I would prefer to have someone to work with on this instead of doing it all myself as my work load for my company has increased dramatically lately (yes... running a consulting company takes time and effort). My sincerest apologies to Serge, but I would appreciate it if anyone who is interested in maintaining PC would let me know. Maybe it is worth to merge ProjectManager (http://home.gna.org/pmanager/) which seems to have better text editing (syntax highlight, rulers). Copyright assignment from Sašo is probably needed. Yen-Ju Thanks, GJC -- Gregory Casamento ___ 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: Project Center status, or lack thereof...
Saso, I believe that the FSF has copyright assignments available for many different countries to deal with the local laws in each. I won't touch the debate on the GPLv3 issue at this time, as I know it's a sensitive issue for some and that's not the point of this discussion. :) I haven't looked at PM in a while. I will take a look at it's latest version and we can discuss this in more detail. Later, GJC -- Gregory Casamento - Original Message From: Yen-Ju Chen [EMAIL PROTECTED] To: Sašo Kiselkov [EMAIL PROTECTED] Cc: Gregory John Casamento [EMAIL PROTECTED]; GNUstep Developers gnustep-dev@gnu.org Sent: Sunday, July 8, 2007 6:56:37 PM Subject: Re: Project Center status, or lack thereof... On 7/8/07, Sašo Kiselkov [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I would love to see more work being done on PM (either by me, or others), since I haven't had much motivation lately (nobody used it, at least not that I would know...). Integration into the GNUstep project itself is a problematic issue. I have no problem releasing all code for it under GNU GPL 2 - make no mistake, I love free software and the ideas behind it and I support them. However, recent FSF work on GPL 3 has raised my eyebrows quite often. BSD licenses, on the other hand, appear to me to be a bit too liberal. I just don't see the reason for a copyright assignment, when the same effect can be achieved with a proper free software license (GNU GPL 2), which makes sure that free software stays free. Anyways, I don't want this discussion to turn over into an overly bloated law-oriented flamewar of licenses and copyrights. If we agree that PM in GNUstep is a good thing *based on technical merits* and a copyright assignment is required to do so, I would probably sign it. I think the free software world is lately spending too much time talking about law and too little about code. And besides - in my country the law states that I cannot hand down my copyrights to anything I create :-) I can grant anybody I want the same rights, but my own rights 'stick' forever onto me :-P I share the same view of GPL3 as Saso mostly. There is a GNUstep Non-FSF project: https://gna.org/projects/gnustep-nonfsf/ If ProjectCenter is moved to this Non-FSF project, it will stay in GPL2 in case FSF decides to move the whole GNUstep into GPL3. But I think it is the decision of the future maintainer. So I will stop here. :) Yen-Ju - -- Saso Gregory John Casamento wrote: I believe that this is worth looking into at this point. -- Gregory Casamento - Original Message From: Yen-Ju Chen [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developers gnustep-dev@gnu.org Sent: Sunday, July 8, 2007 1:03:21 PM Subject: Re: Project Center status, or lack thereof... On 7/7/07, Gregory John Casamento [EMAIL PROTECTED] wrote: All, I would like to get this fixed at some point. PC is one of our core applications and it should work with the latest release, but yet it's not gnustep-make 2.0 compliant which, basically, renders it useless. See this comment: As can be seen, I did not create a ProjectCenter packages because the current release ( 0.4.3) does not work with make 2.0! I do request that a new version be release to conform to the current make release. I've been thinking lately about plans to integrate Gorm and ProjectCenter... to have better communication between them.I would prefer to have someone to work with on this instead of doing it all myself as my work load for my company has increased dramatically lately (yes... running a consulting company takes time and effort). My sincerest apologies to Serge, but I would appreciate it if anyone who is interested in maintaining PC would let me know. Maybe it is worth to merge ProjectManager (http://home.gna.org/pmanager/) which seems to have better text editing (syntax highlight, rulers). Copyright assignment from Sašo is probably needed. Yen-Ju Thanks, GJC -- Gregory Casamento ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGkWDEakxhuWWzY78RA/SkAJ9xst3Ep/FS7gzUCeFp4shLX4R8aQCffbYR p1bkqjnYuxJ3rPqIA06GgsM= =I6o0 -END PGP SIGNATURE- ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Moving GNUstep applications to GPLv3
Fred, Since the code is copyrighted by the FSF, I don't believe that we need to contact any of the original contributors to make the change. The licensing is entirely at the discretion of the FSF. Later, GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: GNUstep Developers gnustep-dev@gnu.org Sent: Wednesday, June 27, 2007 4:09:37 AM Subject: Re: Moving GNUstep applications to GPLv3 I support this change as well. We already have the choice for the user of the library in there: This library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. What I am not sure about is, whether we are able to change the license for old code, where the contributor is no longer in contact with us. Does anybody know about this case? Cheers, Fred Gregory John Casamento wrote: Great! What you explained is the intention. Later, GJC -- Gregory Casamento - Original Message From: Nicola Pero [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developers gnustep-dev@gnu.org Sent: Tuesday, June 26, 2007 8:23:27 PM Subject: RE: Moving GNUstep applications to GPLv3 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. I would personally support and welcome this change. 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
Re: Rework of NSView diesplay mechanism
Fred, Thanks for looking into this. I will make some changes and do some tests later this afternoon to see if it corrects the issue. Later, GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developer gnustep-dev@gnu.org Sent: Wednesday, June 27, 2007 4:30:25 AM Subject: Re: Rework of NSView diesplay mechanism Hi Greg, thank you for pointing out this problem. I think that in this specific case the error lies with Gorm. What happens is that the displayRectIgnoringOpacity: method in GormViewEditor calls the super implementation of displayIfNeededInRectIgnoringOpacity:. This method on NSView now calls displayRectIgnoringOpacity:, which isn't a too strange behaviour, but now Gorm ends up in an infinite loop. It is surprising that the code there has ever worked. This was due to a specific implementation in NSView; I wouldn't be to surprised to see that Gorm wont work on Cocoa. The solution is obvious. Replace the super call to displayIfNeededInRectIgnoringOpacity: with one to displayRectIgnoringOpacity:. With the new code in NSView in place you wont even need the displayIfNeededInRectIgnoringOpacity: method, as now all display operations go through displayRectIgnoringOpacity:. And I am even wondering if it isn't possible to move all this code into drawRect:, but I might have missed the point here. I also don't understand the idea behind the currently_displaying variable. Is this really needed? Are you going to change the Grom code, or should I do it? I would prefer that you look at the code, as I don't want to break Gorm. Cheers, Fred Gregory John Casamento wrote: Fred, Upon seeing your notification of these changes... I tested with Gorm. The changes appear to cause Gorm to go into an infinite recursion when trying to select a control (such as a button) in a window. I have entered a bug for this... https://savannah.gnu.org/bugs/?20274. I'm not certain if it's Gorm's problem or the new changes in NSView, but we should look into it. Thanks, GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: GNUstep Developer gnustep-dev@gnu.org Sent: Tuesday, June 26, 2007 1:03:30 PM Subject: Rework of NSView diesplay mechanism I just submitted a change that reworks the NSView display mechanism to us the new method displayRectIgnoringOpacity:inContext:. To me the new code looks a lot more logical and consistent than the old one, but as this may only be a private opinion I would like you all to review and test the new code. I tried to document the display mechanism a bit better. That way you should be able to tell, what I want to achieve with the new code and point out errors in it. What I also would like to know is if there is any perceivable difference in performance. I don't expect any, but you never know. 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
Re: Rework of NSView diesplay mechanism
Fred, You were correct. I replaced the call with the one you suggested and it now works properly. I'm going to test it a bit more to see if there are any other issues. Thanks, GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developer gnustep-dev@gnu.org Sent: Wednesday, June 27, 2007 4:30:25 AM Subject: Re: Rework of NSView diesplay mechanism Hi Greg, thank you for pointing out this problem. I think that in this specific case the error lies with Gorm. What happens is that the displayRectIgnoringOpacity: method in GormViewEditor calls the super implementation of displayIfNeededInRectIgnoringOpacity:. This method on NSView now calls displayRectIgnoringOpacity:, which isn't a too strange behaviour, but now Gorm ends up in an infinite loop. It is surprising that the code there has ever worked. This was due to a specific implementation in NSView; I wouldn't be to surprised to see that Gorm wont work on Cocoa. The solution is obvious. Replace the super call to displayIfNeededInRectIgnoringOpacity: with one to displayRectIgnoringOpacity:. With the new code in NSView in place you wont even need the displayIfNeededInRectIgnoringOpacity: method, as now all display operations go through displayRectIgnoringOpacity:. And I am even wondering if it isn't possible to move all this code into drawRect:, but I might have missed the point here. I also don't understand the idea behind the currently_displaying variable. Is this really needed? Are you going to change the Grom code, or should I do it? I would prefer that you look at the code, as I don't want to break Gorm. Cheers, Fred Gregory John Casamento wrote: Fred, Upon seeing your notification of these changes... I tested with Gorm. The changes appear to cause Gorm to go into an infinite recursion when trying to select a control (such as a button) in a window. I have entered a bug for this... https://savannah.gnu.org/bugs/?20274. I'm not certain if it's Gorm's problem or the new changes in NSView, but we should look into it. Thanks, GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: GNUstep Developer gnustep-dev@gnu.org Sent: Tuesday, June 26, 2007 1:03:30 PM Subject: Rework of NSView diesplay mechanism I just submitted a change that reworks the NSView display mechanism to us the new method displayRectIgnoringOpacity:inContext:. To me the new code looks a lot more logical and consistent than the old one, but as this may only be a private opinion I would like you all to review and test the new code. I tried to document the display mechanism a bit better. That way you should be able to tell, what I want to achieve with the new code and point out errors in it. What I also would like to know is if there is any perceivable difference in performance. I don't expect any, but you never know. 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
Re: Moving GNUstep applications to GPLv3
Great! What you explained is the intention. Later, GJC -- Gregory Casamento - Original Message From: Nicola Pero [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developers gnustep-dev@gnu.org Sent: Tuesday, June 26, 2007 8:23:27 PM Subject: RE: Moving GNUstep applications to GPLv3 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. I would personally support and welcome this change. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Button Cell Images
GNUstep has this class as well... it's in GSNibCompatibility.m. I wrote it originally as part of the keyed-nib decoding mechanism in GNUstep. I wrote it to model the behavior I was seeing on Mac OS X. WHY Apple chose to do it this way I'm not quite certain, but it is one of the classes which is read and unarchived during nib processing and, thus, needed to be present. GJC. -- Gregory Casamento - Original Message From: Christopher Armstrong [EMAIL PROTECTED] To: gnustep-dev@gnu.org Sent: Sunday, June 24, 2007 3:34:44 AM Subject: Button Cell Images Hi I think I've written on this before, but I don't remember getting a reply so I'll try again. I want to put some images into a theme bundle that are to be used as button images for radio buttons and switch buttons. It appears the API for this is incomplete. Someone has been working on it but I am trying to understand what they were doing. From what I can see, button images are currently loaded from the Appkit bundle by using the +[NSImage imageNamed:] API when -[NSButtonCell setButtonType:] is called. I believe the intention is to replace the encoding and decoding of system button images with instances of NSButtonImageSource; there appears to be some code to do this in NSButtonCell.m but it doesn't make any sense. NSButtonImageSource also seems incomplete and it isn't clear what role GSTheme plays in this. My guess is that NSButtonImageSource instances are to be created for each type of button (NSRadioButton and NSSwitch), and they are to be put where -[NSButtonCell setImage:] is. NSButtonImageSource appears to be a hidden class in Cocoa as both QuantumStep and Cocotron have versions of it. I don't understand the part where it only gets stored for the alternate image (not the main one as well). Would someone kindly explain what the intention of this is and how it should work? I have the time to work on it at the moment but I have no idea what should happen. Cheers Chris ___ 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: Button Cell Images
I've been meaning to remove the NSButtonImageSource.m file in SVN. It's not being used and is superflous since the version in GSNibCompatibility is the one which is currently being used. -- Gregory Casamento - Original Message From: Christopher Armstrong [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: gnustep-dev@gnu.org Sent: Sunday, June 24, 2007 7:28:39 PM Subject: Re: Button Cell Images Hi Gregory John Casamento wrote: GNUstep has this class as well... it's in GSNibCompatibility.m. I wrote it originally as part of the keyed-nib decoding mechanism in GNUstep. I wrote it to model the behavior I was seeing on Mac OS X. WHY Apple chose to do it this way I'm not quite certain, but it is one of the classes which is read and unarchived during nib processing and, thus, needed to be present. I didn't know about that version of it but thanks for pointing it out. I was actually talking about the version in SVN under NSButtonImageSource.m that is present but doesn't appear to be compiled as part of gnustep-gui. I'm not entirely sure how this one was intended to work. Regards Chris ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Google SoC progress
Yes, Indeed. :) -- Gregory Casamento - Original Message From: Lars Sonchocky-Helldorf [EMAIL PROTECTED] To: Adam Fedor [EMAIL PROTECTED] Cc: Developer GNUstep gnustep-dev@gnu.org Sent: Wednesday, April 11, 2007 6:36:24 PM Subject: Re: Google SoC progress Thumbs up Adam for managing SoC so well! regards, Lars Am 11.04.2007 um 18:47 schrieb Adam Fedor: The list of projects for the Google SoC is almost finalized. It looks like we will most likely get 2 students this year, both with some pretty interesting projects: http://code.google.com/soc/gnustep/open.html (you may have to sign up to see this...). This is typical for the number of applications we received (the number of projects is fairly well related to our 'popularity' as judged by the number of applications received.) I've also assigned mentors, but it is possible to change this later if there is keen interest from some one - also I expect anyone with interest to stay involved with the project anyway. The number of projects is also related to our performance in previous years, so we should try hard to make this year work as it will help us next year. If you have any last minute questions or comments for the students, please get them out now. I've found out that other projects are fairly rigorous about students they accept - e.g. asking for code samples and judging how they respond to criticism of their code. ___ 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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSAnimation...
With a clean checkout and a clean install, I still get this: Compiling file set_show_service.m ... Linking tool set_show_service ... ../Source/./obj/libgnustep-gui.so: undefined reference to `nsanimation_progressMarkSorter' collect2: ld returned 1 exit status GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Xavier Glattard [EMAIL PROTECTED] Cc: gnustep-dev@gnu.org Sent: Monday, April 9, 2007 7:12:25 AM Subject: Re: NSAnimation... Xavier Glattard wrote: Fred Kiefer fredkiefer at gmx.de writes: For me it looks even worse: Compiling file NSAnimation.m ... In file included from /usr/GNUstep/System/Library/Headers/GNUstepBase/GSIArray.h:138, compilation twice now, with no luck. from NSAnimation.m:53: /usr/GNUstep/System/Library/Headers/GNUstepBase/GSUnion.h:112: error: conflicting types for ‘NSAnimationProgress’ ../Headers/AppKit/NSAnimation.h:164: error: previous declaration of ‘NSAnimationProgress’ was here (...) Did you check out -base ? I made some changes in GSIArray.h Yes, this was my fault, after recompiling base it worked fine. I currently don't have the time to look into this. Form a quick look it is rather a problem in GSIArray than in NSAnimation. But Xavier, when you fix it, could you please also move all the inline functions from the header to the implementation file? We don't want to clutter up the environment for all the users of this header file. Ok. I use these inline in the demo : i will move them in a private header... Great. Could you please also move over to GNUstep indentation and white space rules? It is not too hard you just need to get used to it. Is that so important ?? It actually looks pretty ;-) I will do my best. Let's not start to discuss this. We all hate part of the rules, but we could never agree on any others and it really is best to have one set of formatting standards. I am also on the cairo mailing list and there the rules for code are even stricter then ours (totally different too, of course), but everybody keeps with them. 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
Re: NSAnimation...
It was built with the following compiler: Target: x86_64-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/opt/gcc/4.1.1 --enable-languages=c,c++,fortran,objc,obj-c++ --disable-checking --with-system-zlib --enable-shared --enable-__cxa_atexit x86_64-suse-linux Thread model: posix gcc version 4.1.1 Thanks, GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Xavier Glattard [EMAIL PROTECTED] Cc: gnustep-dev@gnu.org Sent: Monday, April 9, 2007 7:12:25 AM Subject: Re: NSAnimation... Xavier Glattard wrote: Fred Kiefer fredkiefer at gmx.de writes: For me it looks even worse: Compiling file NSAnimation.m ... In file included from /usr/GNUstep/System/Library/Headers/GNUstepBase/GSIArray.h:138, compilation twice now, with no luck. from NSAnimation.m:53: /usr/GNUstep/System/Library/Headers/GNUstepBase/GSUnion.h:112: error: conflicting types for ‘NSAnimationProgress’ ../Headers/AppKit/NSAnimation.h:164: error: previous declaration of ‘NSAnimationProgress’ was here (...) Did you check out -base ? I made some changes in GSIArray.h Yes, this was my fault, after recompiling base it worked fine. I currently don't have the time to look into this. Form a quick look it is rather a problem in GSIArray than in NSAnimation. But Xavier, when you fix it, could you please also move all the inline functions from the header to the implementation file? We don't want to clutter up the environment for all the users of this header file. Ok. I use these inline in the demo : i will move them in a private header... Great. Could you please also move over to GNUstep indentation and white space rules? It is not too hard you just need to get used to it. Is that so important ?? It actually looks pretty ;-) I will do my best. Let's not start to discuss this. We all hate part of the rules, but we could never agree on any others and it really is best to have one set of formatting standards. I am also on the cairo mailing list and there the rules for code are even stricter then ours (totally different too, of course), but everybody keeps with them. 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
Re: NSAnimation...
Fred, Sometimes it helps to have a ton of compilers on your machine. ;) I have just compiled with gcc 4.1.2. This confirms that the problem only shows up on gcc releases prior to gcc 4.1.2. We need to make sure gnustep compiles on gcc releases back to at least GCC 3.x. GCC 2.95 is also supported, but it is not considered a showstopper if it doesn't work on that release. I will go ahead and make the change you suggested to make it work properly on older releases. Later, GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: Xavier Glattard [EMAIL PROTECTED]; gnustep-dev@gnu.org Sent: Monday, April 9, 2007 8:02:03 PM Subject: Re: NSAnimation... Gregory John Casamento wrote: With a clean checkout and a clean install, I still get this: Compiling file set_show_service.m ... Linking tool set_show_service ... ../Source/./obj/libgnustep-gui.so: undefined reference to `nsanimation_progressMarkSorter' collect2: ld returned 1 exit status I had a look at the code and perhaps it helps to remove the static INLINE declaration for this function. Marking it as inline does surely not help, when it is only used as a function pointer. And as far as I remember there where problems with functions declared as static, when uses via function pointers on Windows. But this was years ago and is surely not relevant for your case. This is more a gcc problem, it should complain about the modifiers at compile time and not at link time. Interestingly I am also using Suse Linux, but have a gcc version 4.1.2 and there this problem does not show up. 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
Re: NSAnimation...
Xavier, I am seeing the following error when compiling: Making all for tool set_show_service... Compiling file set_show_service.m ... Linking tool set_show_service ... ../Source/./obj/libgnustep-gui.so: undefined reference to `nsanimation_progressMarkSorter' collect2: ld returned 1 exit status make[2]: *** [obj/set_show_service] Error 1 I have tried to do a clean compilation twice now, with no luck. Thanks, GJC -- Gregory Casamento - Original Message From: Xavier Glattard [EMAIL PROTECTED] To: gnustep-dev@gnu.org Sent: Thursday, April 5, 2007 12:36:50 PM Subject: NSAnimation... Hello all :-) I'm still working on the NSAnimation class, but i can't understand some parts of the specs... I need your opinion. How should the array returned by [-runLoopModesForAnimating] be used ? 1) schedule one timer for each mode in the array ? (so the animation runs whatever the mode will be) 2) start the animation only if [-currentMode] is in the array ? 3) something else ? What should happen if [-runLoopModesForAnimating] is empty or contains only unknown modes ? 1) do nothing and return ? 2) immediatly call [GSAnimator -_animationEnd] and/or [NSAnimation -animatorDidStop] ? 3) wait 'duration' then stop ? 4) something else ? At end a NSRunLoop question : What is the actual difference between [-runMode:beforeDate:] and [-acceptInputForMode:beforeDate:] Which one should i use with an NSAnimation-specific runLoop ? (blocking and threaded mode) Many thnks ! Xavier ___ 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: Stable branches created for make, base, back and gui
Fred, I'm currently in a location where I can access SVN. If you could create a tag or branch of the code prior to your change that would suffice. Thanks, GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developers gnustep-dev@gnu.org Sent: Thursday, March 29, 2007 8:37:31 AM Subject: Re: Stable branches created for make, base, back and gui Hi Greg, if you plan to update your stable branch with the content of the trunk, now is a good time for this. I plan to make a potentially destabilizing change to gui and back later today. Cheers, Fred Gregory John Casamento wrote: Sorry... I forgot to give the name of the branch: The branch is gnustep_stable_20070311 Later, GJC -- Gregory Casamento - Original Message From: Gregory John Casamento [EMAIL PROTECTED] To: GNUstep Developers gnustep-dev@gnu.org Sent: Monday, March 12, 2007 9:05:14 AM Subject: Stable branches created for make, base, back and gui Please commence testing of the code on these branches and make any fixes you feel necessary there in preparation for the upcoming release. Thanks, GJC -- Gregory Casamento ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Summer of Code 2007
Nicola, No, let's not start a new flamewar here, ;-) No one is doing that. I'm not trying to start one by replying, but I just wanted to have a purely technical discussion on this topic. I did have in mind writing a Renaissance GUI Builder because I'd like to see a native Renaissance GUI Builder where the Renaissance philosophy is implemented natively. I do believe that that will require new user interface/design ideas. Ie, I want auto-layout concepts directly built pervasively everywhere into the basic interface. I feel adding Renaissance to Gorm (which has a completely different philosophy) will end up in a patched system that might somehow work but be ugly and meaningless. This is not a true statement. The IBEditors implementations (GormObjectEditor, GormViewEditor and subclasses) control the behavior of each element in the gui while it is being edited. Gorm and IB are not strictly fixed position editors. It is not impossible (nor against the paradigm of IB or Gorm, as you suggest) to create an IBEditors implementation that takes Renaissance behaviors into account and even allowed them to dynamically resize the way they should in Gorm. Gorm and IB are open ended gui editors and do not lock you into one given paradigm. That being said, the existing editors and inspectors in Gorm and IB do not currently have this functionality, but only because it's never been implemented, not because it's not possible. When I refactored Gorm to handle nib files, I made it so that the internal data structures were simplified. How Gorm internally stores the gui elements is not necessarily tied to a given format. The nib and gorm and gmodel writer classes all take those data structures and transform them into what is needed for output. The same could be done for .gsmarkup. The only information currently missing in .gsmarkup files is metadata concerning custom classes (i.e. which instances are subclasses of other known classes) and classes added during editing (an equivalent to data.classes in a .gorm package or classes.nib in a .nib). The saving or non-saving of default values also could be built into the editors or even into the writer class which writes the .gsmarkup file out. Nobody needs to worry anyway as I don't have time to write a Renaissance GUI Builder myself ... unless I stop working on gnustep-make of course. ;-) I'm not worried, actually, I wouldn't mind seeing something like this happen. What I want to avoid is needless duplication. If a native solution is what you insist on, then I would encourage you to take a look at what can be reused from Gorm, since it is a huge amount of work. This would be useful since it could result in the creation of a general GUI builder toolkit of some kind arising out of Gorm's code. But... for the sake of the Google SoC, it's probably best if we concentrate on those areas in which we are sorely in need of help. Currently, a Renaissance GUI builder would be interesting, but not essential. Later, GJC -- Gregory Casamento - Original Message From: Nicola Pero [EMAIL PROTECTED] To: Fred Kiefer [EMAIL PROTECTED] Cc: Developer GNUstep gnustep-dev@gnu.org; Adam Fedor [EMAIL PROTECTED] Sent: Thursday, March 15, 2007 1:56:47 PM Subject: Re: Summer of Code 2007 Can we add 'Writing a Renaissance GUI Builder' to the list of tasks ? I volunteer mentoring a student doing that. It's a pretty tough job though, so only determined people! ;-) No, lets not write a new GUI Builder here, No, let's not start a new flamewar here, ;-) Your idea could be good and I respect it, feel free to volunteer for it (or for mentoring it) but it's not what I had in mind. :-) I did have in mind writing a Renaissance GUI Builder because I'd like to see a native Renaissance GUI Builder where the Renaissance philosophy is implemented natively. I do believe that that will require new user interface/design ideas. Ie, I want auto-layout concepts directly built pervasively everywhere into the basic interface. I feel adding Renaissance to Gorm (which has a completely different philosophy) will end up in a patched system that might somehow work but be ugly and meaningless. I have nothing against a Gorm pluging for Renaissance though. You can mentor a Gorm plugin for Renaissance if you want. I volunteer to mentor writing a Renaissance GUI Builder though. ;-) I also suggest we stop the discussion here and accept that we have different views. We all thought a lot about this and we came to different conclusions. Nobody needs to worry anyway as I don't have time to write a Renaissance GUI Builder myself ... unless I stop working on gnustep-make of course. ;-) 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
Re: Summer of Code 2007
Nicola, Having thought about this type of thing a great deal, extending Gorm to read and write Renaissance files as well as adding editors to handle the different editing situations would be better than creating a gui builder from scratch. Gorm currently has an architecture which allows easy addition of different formats. I implemented this when I added support for XML based nib files. Each format has a builder and reader class associated with it (.gorm and .nib do... .gmodel only has a reader, since it's not an outgoing format, but it would be possible to write one). Later, GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Developer GNUstep gnustep-dev@gnu.org; Adam Fedor [EMAIL PROTECTED] Sent: Thursday, March 15, 2007 12:57:03 PM Subject: Re: Summer of Code 2007 Nicola Pero wrote: I looked at the stuff, and the money is pretty good for students -- it looks like it's 4,500 USD in total for the Summer job ? :-) Can we add 'Writing a Renaissance GUI Builder' to the list of tasks ? I volunteer mentoring a student doing that. It's a pretty tough job though, so only determined people! ;-) No, lets not write a new GUI Builder here, but add a plugin to Gorm that is capable of reading and writing Renaissance files and of handling the layout elements. Reading will be fairly easy, it is the writing that is hard as we only want the changed attributes to show up. And if we have a solution for that, I would also like to see that used for keyed value encoding. The only idea I have here is to create a default object of the same class and only write out the attributes that are changed from the default, but event that may be to much information. 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
Stable branches created for make, base, back and gui
Please commence testing of the code on these branches and make any fixes you feel necessary there in preparation for the upcoming release. Thanks, GJC -- Gregory Casamento ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Stable branches created for make, base, back and gui
Sorry... I forgot to give the name of the branch: The branch is gnustep_stable_20070311 Later, GJC -- Gregory Casamento - Original Message From: Gregory John Casamento [EMAIL PROTECTED] To: GNUstep Developers gnustep-dev@gnu.org Sent: Monday, March 12, 2007 9:05:14 AM Subject: Stable branches created for make, base, back and gui Please commence testing of the code on these branches and make any fixes you feel necessary there in preparation for the upcoming release. Thanks, GJC -- Gregory Casamento ___ 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-make experiment
Nicola, Have we even tried, experimentally, doing this refactoring to see if it actually would make things simpler? The best way to prove a point is code. I would like to see if it can be done. While I understand it's not *strictly* needed for FHS compliance. it is something that many developers, outside of GNUstep, use on a daily basis. If someone can produce a patch which would simplify gnustep-make that uses pkg-config, I really don't see a reason not to consider including it. Later, GJC -- Gregory Casamento - Original Message From: Nicola Pero [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: Richard Frith-Macdonald [EMAIL PROTECTED]; Andrew Ruder [EMAIL PROTECTED]; gnustep-dev@gnu.org Sent: Tuesday, February 13, 2007 1:20:31 PM Subject: Re: gnustep-make experiment 1) Is pkg-config critical to the goal of FHS compliance? No. 2) Can we leverage it to simplify gnustep-make? No, but you can leverage it to make it even more complicated! ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Guy, I've been reading through this thread and it has gone on for a long while and I'm sorry that I haven't chimed in until now. I'm sorry to say, but, on the one hand I'm not sure that I see the benefit of creating our own home grown solution to a problem that has been solved by pkg-config.On the other hand, I'm mindful of what Nicola said with respect to GNUstep-make dynamically generating the configuration parameters. My questions are: 1) Is pkg-config critical to the goal of FHS compliance? 2) Can we leverage it to simplify gnustep-make? If the answer to either of these is yes then I feel it's something that we should explore. Later, GJC -- Gregory Casamento - Original Message From: Richard Frith-Macdonald [EMAIL PROTECTED] To: Andrew Ruder [EMAIL PROTECTED] Cc: gnustep-dev@gnu.org Sent: Tuesday, February 13, 2007 9:01:49 AM Subject: Re: gnustep-make experiment On 13 Feb 2007, at 13:39, Andrew Ruder wrote: On Tue, Feb 13, 2007 at 06:18:54AM +, Richard Frith-Macdonald wrote: An extra dependency most emphatically IS an issue ... because the 'people' you are referring to actually just means 'you', and you are just guessing about other users, and even assuming that 'most' is actually the case, then what you are proposing is to have something that only works for 'most', not for all. Is your guess that 'most' is 55%, 70%, 95%? At what point is the remaining 45%, 30%, 5% sufficiently small a minority that they become a non-issue? First off, pkg-config is a developer dependency. Users of gnustep applications that have them packaged by their distribution will not have to worry about pkg-config. For what it is worth, some of our dependencies are already using pkg-config (libxml2, sqlite3, libart, libpng, freetype, etc.). Is the implication here that developers using a cross platform development package don't matter? Second off, as pkg-config is a *developer dependency* far less worry should be put into making it a dependency. If you are an actual developer, I'd hope you have the capability to get a few extra dependencies sorted (especially considering that pkg-config IS available on so many distributions at this point). Sure I can, but I shouldn't have to unless I gain some considerable benefit from doing so. GNUstep is supposed to be a cross-platform development system, and anyone who actually does cross platform development would hit a problem with pkg-config. Are we talking about windows here or what? Seems like most of the time cross-platform means windows, Windows, Solaris, MacOS-X that I know of. I guess most gnu/linux systems have it, but most others don't. and once again, pkg-config should be able to be compiled/setup on windows. That's missing the point. Unless we supply it with the system and automatically install it, it's another hurdle. We already have too much installation of dependencies to do (particularly on windows), and should be working to automate things to make existing dependencies less painful. Dependency issues do not rule out using things (indeed, GNUstep has plenty of dependencies), but they are a big factor to consider, and only appear minor to the people they don't happen to effect, so when adding a dependency we need to be clear that what we are adding has overwhelming advantages over the alternatives. While pkg-config is quite nice (and looking at it provides inspiration), it has no such advantages. There is one major advantage that pkg-config does provide here and that is simply that we are not maintaining it. Everytime we work around having another standard system service by reimplementing it in our codebase, sure we save a 'dependency', but at the same time we have more code that we have to support and that is never a good thing. Well, that's a different issue than dependencies, but as Nicola pointed out, using pkg-config means we have to support it in terms of providing the metadata files it depends upon ... and that's actually as much work as (or more than) just building our own stuff. So in terms of maintenance and development effort required, the use of pkg- config is an additional burdon, not a time saver. ___ 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: 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
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
Re: Delay of release....
Fred, I understand and agree with Richard on this. We will give the gui trunk some time to stabilize before making a release. Also, there are some bugfixes which should be made for quality sake prior to the release. Thanks, GJC -- Gregory Casamento - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developers gnustep-dev@gnu.org Sent: Monday, January 22, 2007 7:34:00 AM Subject: Re: Delay of release Gregory John Casamento schrieb: My sincerest apologies on the recent delay of the release. I have been working on correcting a few bugs prior to the release and other events have delayed me as well. The release should be made in either Monday or Tuesday. Thanks for your patience, Oops, are you talking about a release of gui trunk or are you planing a bug fix release for gui? The late case should be alright, but there might be a problem, if you are going to push out the current trunk of gui as a release. I made some changes that will break backward compatibility and am about to make a lot more of such changes. As you know I did delay these changes for some time to give you time for a release, but as that time did expire and Richard explained, that I should not wait any longer (at least this was how I understood his mail), I started with these changes. So, if you are planing a gui release, please do some checking of my changes first (NSControl!!!) and perhaps wait for another week to give me the chance to finish off the changes to NSButtonCell as well. With that in place we will have a system that is hopefully a bit more stable than the current state. Sorry for the misunderstanding Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Delay of release....
All, My sincerest apologies on the recent delay of the release. I have been working on correcting a few bugs prior to the release and other events have delayed me as well. The release should be made in either Monday or Tuesday. Thanks for your patience, GJC -- Gregory Casamento ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
