discuss-gnustep
[Top][All Lists]
Advanced

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

Re: New ProjectCenter Icons


From: Richard Frith-Macdonald
Subject: Re: New ProjectCenter Icons
Date: Thu, 13 Sep 2007 14:48:01 +0100


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.



reply via email to

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