Re: New ProjectCenter Icons

[Gregory John Casamento]

> Well, I just argument for "one application that does one thing well:  
> increase productivity when developing great applications by helping  
> the developer with his different tasks". 
I resisted saying it in my previous email...  but I believe that you know 
perfectly well that this is not what I meant.

"Improving" our development environment is NOT what GNUstep needs to 
concentrate on right now.

We need more applications.  Period.

GJC

--
Gregory Casamento

----- Original Message ----
From: Dr. H. Nikolaus Schaller <hns@computer.org>
To: Gregory John Casamento <greg_casamento@yahoo.com>
Cc: discuss-gnustep@gnu.org
Sent: Friday, September 14, 2007 3:34:58 AM
Subject: Re: New ProjectCenter Icons

Gregory,

Am 14.09.2007 um 07:27 schrieb Gregory John Casamento:

> Nikolaus,
>
>> What I still do not understand is why almost all arguments against my
>> proposal finally end up like (well I am making it quite black&white):
>>
>> "It is already good how it is solved (because it comes from
>> NextStep). Well, Xcode/I[B] have now something that is missing in
>> GNUstep/PC/GORM. So we just have to add the missing things, i.e. some
>> DO between PC and GORM and FileMerge to interact between both and
>> everything is fine."
>
> Since you're making it "black & white" allow me to as well:
>
> As I said in a previous email... I'm a big believer in the "have  
> one application do one thing and do it well" philosophy.  Gorm is  
> very good at modifying GUIs... it doesn't need to be built into a  
> monolithic IDE (even as a module) in my opinion.

Well, I just argument for "one application that does one thing well:  
increase productivity when developing great applications by helping  
the developer with his different tasks".

GUI-design and coding is - in my view and practice - so much combined  
that separating into different applications is like having separate  
paragraph style editor applications and table editor applications  
when creating documents. And another one for making the table of  
contents. And another one for footnotes.

Or another example: Xcode does some SVN integration. It could as well  
be a completely separate SVN manager application - but I am not sure  
if the useability is the same.

> What you're talking about is something like Eclipse.  I use Eclipse  
> on a daily basis... it's nice, but it's slow and it's also an  
> enormous memory hog.

I have never used Eclipse and therefore have no idea why it is slow  
and needs a lot of memory. But I think it is not necessarily because  
it is monolithic.

>
>> I am sure, there are better (from a user's point of view) solutions
>> than copying Xcode/IB...
> We are NOT blindly copying.   There are a lot of things in Xcode  
> which will never, I hope, be put into PC.  Things like the UML tool  
> and the Data modelling tool don't belong in Xcode as far as I'm  
> concerned.   After you mentioned it the other day I went and looked  
> at it in Xcode (I had never really played with it before).   I  
> remember literally thinking how it felt like it should have been a  
> completely separate application.

I have no experience with that either, but it may be daily work for  
someone who uses CoreData and Bindings and they *may* like the  
integration.

> There is no reason why the level of integration you want can't be  
> reached by using DO.

Yes, you can do anything with DO as well. You can even have one  
application modify the NSView or NSMenu tree of another one (if you  
have a proxy for the NSApplication). So, the central module could  
provide an empty NSView and all the other applications use DO to fill  
in their NSView subtrees.

But it is inherently slower and needs more memory because you have  
two applications to load into memory and provide time slices for both  
plus the communication between them. So if you are concerned about  
speed and memory demand, I would *not* recommend to use DO but  
optimize a monolithic approach!

And (I think I am repeating myself): what happens if the other  
application is not available for some reason (hangs, crashed, etc.)  
and DO access fails. You have to take care of these situations and  
provide a fallback, which expands the code and complexity of the  
module-applications again.

Conjecture: separate applications communicating through DO need more  
memory and are slower than a monolithic application (on a single- 
processor system).

> You seem to be taking the direction of "anything which differs from  
> what Apple is doing *must* be good."   That view is equally as  
> meritless as the "everything Apple does is right"

No, my view is: "different" does not necessarily result in "better".  
But to be "better", you must be "different". From your current status  
and from what Apple provides.

> view which you claim that everyone who disagrees with you is  
> espousing.   I don't think that everything Apple does is right.    
> That's why I'm advocating making a number of apps which collaborate  
> together via DO instead of a monolithic memory hogging monstrosity  
> like Xcode. ;)

And, my view is that none of the existing solutions is generally  
"good" - since there is no absolute scale. So, I feel the permanent  
need to search for "better" solutions and that is the reason why I am  
discussing this here...

But maybe, we should get some more feedback from daily users of PC  
and GORM what they would like to improve. And then find out how.

Nikolaus