Re: New ProjectCenter Icons

[Dr. H. Nikolaus Schaller]

Am 11.09.2007 um 09:24 schrieb Richard Frith-Macdonald:

> On 11 Sep 2007, at 07:00, Dr. H. Nikolaus Schaller wrote:
> > My argumentation is for b), because it would allow features that  
> > are quite difficult to integrate or operate in approach a) like:
> >
> > * single "edit" window in PC for all kinds of project components -  
> > without switching applications
>
> I actually prefer to have separate, apps for editing different  
> things ... then their gui can be better tailored to the specific task.
>
> > * project wide "Search" including NIBs
>
> You could have a standard search API ... distributed objects lets  
> you ask each app to search documents handled by that app.  I don't  
> know why NeXT never did that (or why Apple haven't added it).
>
> > * double-click on a Class in the NIB editor will jump to the  
> > @interface in Source file
> > * double-click on Action method will jump to the @implementation  
> > in Source
> > * NIB editor simply "knows" the IBActions a class provides
> > * NIB editor simply knows the IBOutlets a class provides
> > * dragging an image on a NIB adds the file to the sources
> > * etc.
>
> All the above can be easily done by having one app send a  
> distributed notification which another app observes.
> eg. if you want project center to select a class in its editor, it  
> just needs to watch for the notification saying that the class has  
> been clicked on.

But the user has to switch between applications and windows although  
he is doing the same task: updating a component of a project.

An integrated approach could also "disassemble" a NIB file and show  
its contents as virtual file types, e.g. menus, controllers, windows,  
views etc. and provide individual editors for these.

Think about this GUI layout (hope that it is not corrupted by mail) -  
click on any project component and it shows up in an editable way

++++++++++++++++++++++++++++++
! file.h     !*MainMenu******!
! file.m     ! FirstResponder!
!*file.nib***! Controller2   !
! file.plist ! Window17 >    !
++++++++++++++++++++++++++++++
!    here either source      !
!         Menu               !
!         Window             !
!          View              !
!                            !
++++++++++++++++++++++++++++++

My main target for this discussion is to think about how GNUstep  
could revolutionize IDEs by making things really simpler for daily  
work... This might help to attract new developers and users. So, it  
is more to be seen as a feature request for PC/GORM 2.0

BTW: what I still find the most complex way of editing NIB files is  
dragging of connections (at least in Apple's IB)... A simple popup  
list for selecting the target of an object would be much easier to  
operate for daily work than dragging a line between two objects...

> > I know that this is quite a shift away from the original NextStep  
> > approach, but why not try if we can make life easier for the  
> > developers?
>
> I think the beauty of the NeXTstep approach is that it provides  
> rich, easy to use, interprocess communication (NeXTstep was really  
> designed around that) ... apps can ask each other to do jobs for  
> them and

Yes, I agree on the beauty from a developer's point of view... But a  
user or PC/GORM/xyz doesn't care how it is implemented and just sees  
two separate applications :-(

> can send notifications that other interested apps can observe ...  
> so you can provide an integrated development experience using a  
> variety of smaller applications rather than having to have a single  
> huge monolithic application.  You get the best of both worlds.

Yes, it can be used to integrate separate applications (and I like  
the DO approach and use it heavily for QuantumSTEP).

But after a while it becomes quite complex to maintain:

* what if the other application does not run or respond?
* you have to agree and define a common protocol and keep it stable  
across different release schedules
* implement more and more methods/messages to send through DO