Re: Missing class in gui.

2006-03-25 Thread Gregory John Casamento
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.

2006-03-25 Thread Fred Kiefer
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

2006-03-25 Thread Richard Frith-Macdonald


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

2006-03-25 Thread Stefan Urbanek

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?

2006-03-25 Thread Andrew Ruder
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