[Top][All Lists]

[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: Wed, 12 Sep 2007 08:21:10 +0200

Am 12.09.2007 um 03:23 schrieb Gregory John Casamento:


Yes, they are integrated, but I would not agree that they are *well*
integrated. I can imagine a lot of areas where integration could be
I'm wondering if you could elaborate on that a little.

1. if you select a target/action connection in GORM, directly switch with the source file of the action method 2. if you select and edit an outlet, directly switch/generate/updatee the IBOutlet definition in the source code 3. parse the source files to have a Class tree and directly use/edit that in GORM
4. you can save the "Save" and "Open" menus in IB
5. Save All... also saves changed NIB files
6. Search&Replace in Sources and NIBs in a single step
7. a single Windows menu - reduce the number of open (and overlapping) windows to switch between (i.e. there is an "Inspector" in Xcode and one in IB)

All this can be done using DO, but IMHO it becomes quite complex.

And it is the basic question: should PC and GORM follow what Apple is
doing or try to go a different - potentially better way?

PC and Gorm should stay the way they are, because this is the better way. Each tool has a specific purpose. I'm a big believer in the "doing one job well" philosophy. A monolithic IDE like Eclipse for GNUstep doesn't appeal to me.

That is ok. For me, an IDE has a specific purpose: help me to create great Applications and it should do this one job well. I do not split that task up into parts like editing source, editing NIBs, compiling etc. because I favour a holistic approach towards the result of the Application design task.

But there are different habits and philosophies.

Xcode got so complex because it even includes a Class browser and a
Data Entity relationship modeler (a graphical tool!) for defining the
CoreData models. I have really no clue why Apple decided to integrate
that into Xcode and not IB or vice versa...

Yes, as you said, it got complex. I, personally, believe that including the data modeler and the class modeler/browser into Xcode was a mistake. If those are done for GNUstep, and they probably will be at some point, I don't believe that they should be part of PC, but that they should be separate applications.

You can also open Source code files in Xcode without having a
project. So, why should it not be possible to open NIB files without
a project?

I don't really count this as a feature of any kind. I think it's sad that you're starting up an app which has a class modeler, a data modeler, project management code and tons of other things... just to read a source file. So we now have a 10MB application in memory to read a source file... doesn't seem like a big win to me.

Don't we have virtual memory and lazy loading to solve this issue on a quite different level?

Hm - while I like this idea of doing things differently - I always
hear that fragmentation and duplication of efforts is not so good...

Linking with and reusing GormLib doesn't imply any sort of "duplication of effort." This is why it's called "reuse." :)

And the basic question that is driving me into this discussion is not
answered: how can we attract new users and developers?
IMHO one puzzle piece is by starting to develop better concepts than
there are today (e.g. from Apple).

Different != better.

Not necessarily. But: Better must be different.

The plain and simple truth is

1) GNUstep needs more applications
agreed - the quantity is still too small to make it useful for any daily task 1b) GNUstep needs qualitatively better applications (better than those on other systems)
2) GNUstep needs to look better....

That is how we are going to attract developers.

reply via email to

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