Re: New ProjectCenter Icons

[Dr. H. Nikolaus Schaller]

Am 12.09.2007 um 03:23 schrieb Gregory John Casamento:

> Nikolaus,
>
> > 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
> > better.
> 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.