discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New ProjectCenter Icons


From: Dr. H. Nikolaus Schaller
Subject: Re: New ProjectCenter Icons
Date: Fri, 14 Sep 2007 09:34:58 +0200

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]