Re: New ProjectCenter Icons

[Richard Frith-Macdonald]

On 13 Sep 2007, at 14:18, Dr. H. Nikolaus Schaller wrote:

> Am 13.09.2007 um 14:59 schrieb Richard Frith-Macdonald:
>
> > On 12 Sep 2007, at 17:45, Dr. H. Nikolaus Schaller wrote:
> >
> > > Am 12.09.2007 um 18:16 schrieb Wolfgang Lux:
> > >
> > > > Dr. H. Nikolaus Schaller wrote:
> > > >
> > > > > That works only if your class has just IBOutlets (IB is not  
> > > > > showing and handling any other ivars!). And any changes made  
> > > > > manually to the .h file are overwritten.
> > > >
> > > > On my system (OS X 10.4) IB asks whether I want to replace the  
> > > > existing files or merge the changes, and if I choose the latter  
> > > > it happily invokes FileMerge for both the header and the source  
> > > > file. Obviously, this means that we need an equivalent of  
> > > > FileMerge in order to get this to work under GNUstep :-(
> > >
> > > Yes, it also works this way.
> > >
> > > If you are asked three times per hour by the development  
> > > environment to replace or merge and then a third (!) application  
> > > opens where you have to click around, you will probably start  
> > > looking for simpler solutions...
> > >
> > > 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/IP 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."
> >
> > I guess that's because most people think that separate apps  
> > integrated via DO and distributed notifications will provide a  
> > better user experience than a monolithic application that does  
> > everything.  My favorite example of the app that does everything  
> > is microsoft word ... which I find utterly unusable.  You either  
> > live with a huge amount of clutter in toolbars and
>
> 200% agreed! Apple has shown with Pages how the same amount of  
> functions (and document file compatibility) can be provided with a  
> better UI design.
>
> > menus, or you customise it to the point where it's completely non- 
> > standard, and you can't effectively use anyone elses customised  
> > version.
> >
> > > I am sure, there are better (from a user's point of view)  
> > > solutions than copying Xcode/IB...
> >
> > I guess so (I'm not too keen on Xcode) ... but I don't think a  
> > monolithic app is one of them.  I would prefer to go the other  
> > way ... more small apps tailored to their specific jobs, and  
> > integrating with each other.  Technically, I think that well  
> > defined interfaces between apps using DO/notifications are no  
> > harder to program than well defined interfaces between
>
> Hm, if you replace "apps" with "views" and integration "through DO"  
> with "classes (potentially from loadable bundles)" - where is the  
> difference for the user?

The difference for the user is that they only use the apps they want/ 
need rather than having to have everything on-screen, and that the  
user interface of each app can be tailored to the job that app is  
meant to do.

> > modules in the same app ... and you need such modularisation for  
> > maintainability in any large project whether its multiple apps or  
> > multiple modules in one app.
>
> Generally, I think we are mixing features / user interface design  
> with application architecture and are argueing that a DO based  
> multi-application architecture can improve the user experience.

That's not my intention ... I was not saying that the technical  
features improve the user experience.  What I was saying is that the  
technical facilities we have available mean that a multi-app approach  
can achieve the same degree of integration that a single app approach  
can, with no maintainability/complexity overhead.  In other words, a  
monolithic app has no technical advantage when it comes to  
integration of features in an IDE.

> I would keep it simple anyway. My vision is (like I have tried to  
> draw with ASCII characters in a previous mail):
>
> * a single NSBrowser to select items (source file, NIB item, Makefile)
> * a single View (NSTabView with invisible tabs) area where you  
> either see source code (NSTextView) or Menus or a NSWindow with  
> NSView hierarchy or a property list (NSOutlineView)
> * an inspector for attributes of the currently selected item (which  
> can be a source file or a NIB item)

For me, the second of those (single view to display everything) is a  
bad thing ... I want multiple views to show different parts of my  
work on screen at the same time.
I guess if I was using a handheld machine (rather than the 21"  
display I actually use) I'd want to put everything in just one view  
though.

I think it's only the single view for all things that is at all  
tricky to do with multiple apps.
My view of the perfect ide would be more like a single window which  
browses the source/resources in the project and lets you activate the  
app which handles each file.  An inspector which lets you customise  
build options, and a few menu items (to build and launch a debug app  
etc).  Everything else would be handled by other apps.