Re: Missing class in gui.
Once they are complete I would really like to start testing them in Gorm. :) Looks cool. --Gregory John CasamentoPrincipal Consultant, Open Logic Corp.# Maintainer GNUstep GUI/Gorm- Original Message From: Fred Kiefer <[EMAIL PROTECTED]>To: Gregory John Casamento <[EMAIL PROTECTED]>Cc: GNUstep Developers Sent: Saturday, March 25, 2006 6:49:12 PMSubject: Re: Missing class in gui.Sorry, this was my fault. When submitting the patch for NSStepperCellthis other change went through unnoticed. Thank you for fixing it.I will now submit these files although they are still not complete, butotherwise I may produce the same problem once more.CheersFredGregory John Casamento wrote:> I removed references to NSSearchField.m and NSSearchFieldCell.m since> they don't current exist in the repo, once they are checked in please> add them back into GNUmakefile.> > - Original Message > From: Gregory John Casamento <[EMAIL PROTECTED]>> To: GNUstep Developers > Sent: Thursday, March 23, 2006 9:07:31 PM> Subject: Missing class in gui.> > Compiling file NSSavePanel.m ...> make[2]: *** No rule to make target `shared_debug_obj/NSSearchField.o',> needed by `shared_debug_obj/libgnustep-gui_d.so.0.10.3'. Stop.> make[1]: *** [libgnustep-gui.all.library.variables] Error 2> make[1]: Leaving directory `/home/heron/Development/gnustep/core/gui/Source'> make: *** [internal-all] Error 2> ___Gnustep-dev mailing listGnustep-dev@gnu.orghttp://lists.gnu.org/mailman/listinfo/gnustep-dev___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Missing class in gui.
Sorry, this was my fault. When submitting the patch for NSStepperCell this other change went through unnoticed. Thank you for fixing it. I will now submit these files although they are still not complete, but otherwise I may produce the same problem once more. Cheers Fred Gregory John Casamento wrote: > I removed references to NSSearchField.m and NSSearchFieldCell.m since > they don't current exist in the repo, once they are checked in please > add them back into GNUmakefile. > > - Original Message > From: Gregory John Casamento <[EMAIL PROTECTED]> > To: GNUstep Developers > Sent: Thursday, March 23, 2006 9:07:31 PM > Subject: Missing class in gui. > > Compiling file NSSavePanel.m ... > make[2]: *** No rule to make target `shared_debug_obj/NSSearchField.o', > needed by `shared_debug_obj/libgnustep-gui_d.so.0.10.3'. Stop. > make[1]: *** [libgnustep-gui.all.library.variables] Error 2 > make[1]: Leaving directory `/home/heron/Development/gnustep/core/gui/Source' > make: *** [internal-all] Error 2 > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cairo as common graphics context
On 25 Mar 2006, at 19:46, Stefan Urbanek wrote: I'm not going to go further with the discussion about whether the state of the project can be tracked from the mailing list and changelogs ... we will have to just disagree about that ... you say it cannot, but it's what I do. Of course there are a lot of other supplementary resources (bug tracker, wiki etc) but the mailing lists and changelogs are undoubtedly the primary ones I use. Same problem again. "We need new coders". But new coders need to know: - what is the state of the project - what parts need help - what kind of help is needed (very concrete om the form: feature/ functionality is not implemented and is crucial for this or that) - what is needed for implementing the missing feature/functionality (this should be filled by anyone who knows the best the area) (*) - ... (*) and THIS is the reason WHY ANY input from core developers is more than crucial. Noone is expected to actualy code anything, but what is expected to make the project progress is that who knows how to do something, should give the knowledge to others. All very well, and we have the project task list, bug list, and wiki stuff for this, but it's fundamentally only workable up to a point ... after which people need to ask specific questions. The fact that we already HAVE the mechanisms to inform people is proof that it's not the lack of these that is causing a problem ... but rather the lack of manpower (both to code and to keep communications etc up to date). If anything, we may have too many mechanisms for communicating information about the project status. I did not expected that anyone will immediately start coding anything, as Alex mentioned in his previous email in this thread. I was upset, because there was NO input from people responsible, nor an impulse from anyone to the responsible to give the input. From my reading of the mailing list, I saw your initial query at 14:53 on the 15th, and Adam's response about 30 minutes later. Now I understand that it wasn't the sort of response you wanted ... but I'm confident that that was because he assumed (reasonably imo) that you were a developer. And had you actually been a developer intent on coding, a dialogue in which detailed questions were posed and answered would probably have ensued. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cairo as common graphics context
Hi, Excuse me for the late reply, I was ill for couple of days. Second excuse goes to my last email, as I did not stated it perhaps that you should take it with less weitht than it was written ... but that is common problem of all electronic communication. On 17.3.2006, at 16:41, Richard Frith-Macdonald wrote: On 17 Mar 2006, at 00:21, Alex Perez wrote: Fred Kiefer wrote: ...It looks like I am currently the only GNUstep developer working on back and the interaction between back and gui and also specifically on the cairo backend. Were you not aware of this prior to this exchange of e-mails? Yes he was. I can say that with confidence for two reasons ... 1. Everyone who tracks the developer mailing list and/or the ChangeLogs is bound to be pretty much aware of what's going on. I disagree. With so many inputs, so many interrupts, so many real- life work and other real-life activities, one can easily get lost... Adn a ChangeLog is just ... well ... a log. It is not a project management tool. And it shuold not be, nor it should be thing of as it was. From the project management point of view, I don't think so ... developers all (meaning anyone reading the mailing lists and tracking ChangeLogs) have a good idea of what's going on (or not going on). It's true that newcomers and people who don't track things need to ask in order to find out what's happening, but I'm not convinced that that constitutes a problem. Se above. Even if you read each message on the list, I do not believe that you will have a large picture of the project, nor you learn current state of the whole project. If you (anyone can), then I will bend myself, come to him and ask him, whether he can teach me how to do that... It would be really good to have nice up to date summary on the website/wiki for end users of course, but is it worth diverting the effort of the few coders we have to maintaining that? I think not. It's hard enough to write decent messages for ChangeLogs and svn commits as most coders (I include myself here) are not great at communications :-( Why for the "end users" only? What about GNUstep dashboard updated, for example, monthly? This was good for end users: http://web.archive.org/web/ 19990218113209/www.gnustep.org/AboutGNUstep/ProgressOverview.html Something similar can be for developers, but with better breakdown. AND with "assigned" developers (= the ones who know about the module the most). Adam is not willing to ask anyone (either because there's nobody to ask or because he simply doesn't feel that he should have to delegate/ask anyone else to code anything) and so the problem will continue to the end of time unless something changes. Agreed, but I think much more the former than the latter. We need new coders for the core libraries desperately, and more people to manage the organisation/communications (website/wiki/publicity). Same problem again. "We need new coders". But new coders need to know: - what is the state of the project - what parts need help - what kind of help is needed (very concrete om the form: feature/ functionality is not implemented and is crucial for this or that) - what is needed for implementing the missing feature/functionality (this should be filled by anyone who knows the best the area) (*) - ... (*) and THIS is the reason WHY ANY input from core developers is more than crucial. Noone is expected to actualy code anything, but what is expected to make the project progress is that who knows how to do something, should give the knowledge to others. I did not expected that anyone will immediately start coding anything, as Alex mentioned in his previous email in this thread. I was upset, because there was NO input from people responsible, nor an impulse from anyone to the responsible to give the input. This gave me the impression, that noone cares. And we want new developers? Regards, Stefan Urbanek -- http://stefan.agentfarms.net First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: RSS feed for GNUstep SVN repository?
On Sat, Mar 25, 2006 at 07:27:46AM +, Richard Frith-Macdonald wrote: > --- snip --- > [EMAIL PROTECTED]:(~)$ ls -lA /svn/repos/dragon/hooks > total 4 > -rwxr-xr-x 1 root root 333 Feb 15 21:05 post-commit > [EMAIL PROTECTED]:(~)$ cat /svn/repos/dragon/hooks/post-commit > #!/bin/sh > > REPNAME="dragon" > LOGFILE="/www/webdav.operatelecom.com/html/logs/${REPNAME}.log" > RSS="/www/webdav.operatelecom.com/html/logs/${REPNAME}.rss" > > /svn/bin/SVNTransactionDetailLogAppender.py $1 $2 $LOGFILE > /svn/bin/SVNTransactionDetailLogRDFGenerator.py $REPNAME https:// > webdav.operatelecom.com/${REPNAME} $LOGFILE $RSS > exit 0 > --- snap --- > > The scripts can be found at: http://svn.mulle-kybernetik.com/SVNTools/ > trunk/ That would be cool, but I'm not sure we have any sort of access to the actual repository to add in the post-commit hook. (i.e. you can't add that with only svn:// or svn+ssh:// access). Could probably just as easily write some scripts that grab the same info every few hours remotely and feed it to the RDF generator. Would be handy... - Andy -- Andrew Ruder http://www.aeruder.net ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev